Re: Securing Computer Lab
You can script anything necessary. The easiest thing would be to remove /home/s*/* at reboot and make all student accounts begin with an 's'. Make the sudo/admin account begin with a non-'s' character.
As for security, there are thousands of things to know and only time + experience will gain that knowledge.
Start here: http://linuxcommand.org/tlcl.php
Learn about local user accounts so what is needed and what is optional for each. You'd probably want to dynamically change the password daily for accounts like this too.
Really, there isn't any need to reboot a system. I'd use ansible to remove every student account, delete the HOME, and recreate them as needed. Ansible would run from a trusted workstation. Really, rebooting would be just a way to waste 2 minutes.
Unix/Linux isn't Windows. Reboot seldom is the correct answer.
You can script anything necessary either using ansible or just with simple ssh scripts. Your choice. Ansible works over ssh.
I'm not a fan of Ubuntu Core (registration required to use?!!!) or snaps ( limited hardware doesn't like snaps). Snaps break many things necessary for a corporate environment.
Re: Securing Computer Lab
This is great info, thanks! I have used ansible a bit in the past so that may be a good option for pushing updates and config changes.
I think wiping the home directories would accomplish most of what I’m looking for. I could probably set up a cron job to take care of this.
I’m fairly competent with Linux, so not too worried. I just was not finding a ton of up to date or simple setups for more of a “kiosk” type setup, which I don’t think is necessary. I’m always a fan of providing a computer that’s not locked down to the point of being useless to our students.
Thanks again! Time to mess around with some scripting
Re: Securing Computer Lab
I suspect deleteing the HOME wouldn't be good. The "skel" files probably need to be there, like get places when a new userid is created. That's why I was thinking more about deleting a userid and recreating it when students were done. Do they just walk in and sit or do they have to check in to have access? That would be important to know, since it could be integrated into the process to only delete-create when a new person shows up. Then students could have access to their files for a full day, perhaps, assuming that wiping wasn't too quick.
Kiosk setups are completely different. For those, I'd use a purpose-built TinyCore setup, but I'm assuming intel/amd CPUs. Are these chromeboxes ARM or Intel?
As always, there are 500 solutions. Only you can pick the best based on local knowledge.
Re: Securing Computer Lab
The sessions are usually no longer than a few hours at most. Classes may come in and use the lab, and students are able to come use it on their break or lunch periods.
I’ve looked at things like Porteus Kiosk, but I want to stick with distros supported by the secure test software, that’s kind of the most important thing. Ubuntu is great cause it’s on that list and my preferred
The chromeboxes are intel thankfully.
Wouldn’t deleting /home/s*/* wipe out those .skel files as well?
Re: Securing Computer Lab
Quote:
Originally Posted by
strictbishop
Wouldn’t deleting /home/s*/* wipe out those .skel files as well?
Exactly. Some of my ideas aren't complete, but if your script puts a fresh set of those files back, then no harm. I could see a student changing the default password, however. Maybe deleting the account and re-adding it would be the best answer?
Re: Securing Computer Lab
Anyone with physical access to the computer can get root access, although it may require a screwdriver to open the box. So you must trust your students to some extent.
If you make a generic student login and reset it to defaults every night, one student can still play tricks on a different student using the same computer the same day.
Another way to deal with this is giving each student his own login, with a home directory on some network attached storage. That way they can keep their files for the next day and can't mess with each other's files or the system. Group permissions can be used to allow students to cooperate on larger projects. It'll give the students some useful Linux skills. You'll need a few TB of storage on the network, depending on your number of students and the storage each one of them is allowed to use. You can set disk quota. The admin must be prepared to reset config files to defaults and passwords to temporary strings whenever some student messes up his own account (which will happen frequently) and implement a decent backup routine (which will be needed; people accidentally delete files all the time).
Re: Securing Computer Lab
The least hassle would be to enable the Guest Account.
The guest account works like a kiosk and gets overwritten on each login.
Re: Securing Computer Lab
Quote:
Originally Posted by
HermanAB
The least hassle would be to enable the Guest Account.
The guest account works like a kiosk and gets overwritten on each login.
I thought Ubuntu's guest account was deprecated due to security problems?
Students (or NASA engineers) can screw with others on the same LAN if they like. I've heard rumors, but certainly wouldn't know anything about that first hand. <beg> Only heard about it from friends of friends through a cousin.
Re: Securing Computer Lab
So after some trial and error, I came up with this
Quote:
sudo find /home/student -not \( -name '.bashrc' -o -name '.profile' -o -name '.bash_logout' -o -name '.bash_history' -o -name 'student' \) -exec rm -rv {} +
which seems to do most of what I want as far as deleting the files. I set it up as a cron job to run at reboot