Loosely securing Linux for students to learn on

Question

At school, we have a computer that is only for students to login to and do computer science related activities, such as compiling C and C++ programs for classes. It was running some obscure flavor of linux that was put on many many years before I took it over. I have recently installed Ubuntu Server on it to make it more maintainable and secure. Currently we set up user accounts as needed. Students ssh login and complete assignments for class and each user stores their work and play in their home folder. The instructors will have the students leave their work in a certain folder for submitting or something like that.

My concern is a user that gets too exploratory and explores or someone maliciously trashes it and breaks something, thereby causing no one else to be able to get any work done, and results in the faculty complaining to me and making me look like a bad sysadmin for not preventing this. (I am still an undergrad and at their mercy)

The students are currently in their own group, and can only see their own home folder / can't browse other students folders. Faculty have more advanced accounts but not admin accounts. I am reluctant to start changing permissions on important system folders worrying that I may break something (again as I have done before).

What safety measures can I take to ensure functionality of the system while keeping it secure so everyone can enjoy and use it?

Answer 1

I ran a roughly similar project while in college (we had more than one server, and weren't really answerable to anyone bar computer services, but we were linux boxes for students). In terms of security, mostly it's about keeping absolutely up to date with patches. Where necessary, switch off login, if there are local root vulnerabilities, and no patch out yet. You also want to set up ulimits. How sevre these are is probably dependent on how powerful your machines or, but our least powerful machine used these:

-

t: cpu time (seconds)         18000
-f: file size (blocks)         307200
-d: data seg size (kbytes)     51200
-s: stack size (kbytes)        8192
-c: core file size (blocks)    0
-m: resident set size (kbytes) 51200
-u: processes                  75
-n: file descriptors           300
-l: locked-in-memory size (kb) 175000
-v: address space (kb)         400000
-x: file locks                 unlimited
-i: pending signals            61440
-q: bytes in POSIX msg queues  819200
-e: max nice                   0
-r: max rt priority            0

As well as this, you'll want to set quotas, probably for both faculty and student accounts. How large they are is dependent on your disk, but we currently set 1GB quotas by default. I believe my successors looking after the machines are generally quite happy to up those however for people who've got any kind of a valid reason.

As well as this, I'd beg/borrow/steal a second machine if at all possible to back up your configuration/user data. Ideally you should be backing up all of /etc/, a list of your installed packages, and and all of your user data (If you have any packages you've put together yourself, you should be backing up the full .debs). If you've got the space, I'd backup /var, (except /var/tmp) as well.

Permissions on /root are 755 by default. you'll want to change these, since you will leave sensitive files there accidentally at some point. Also, wall and su (at least) should have their permissions changed so only root/root group can use them (feel free to change the root group for some other group that only you're in).

Finally, I'd syslog everything to remote server, with no user logins (even if this isn't a machine controlled by you). I'd setup snoopy on your machine, so you have some kind of audit log for when someone breaks in.

Our docs for most system stuff are here. Most of them probably don't apply to you if you're only running a single machine, but they may be worth poking through bits of anyway.

Answer 2

There are basically two ways of going about this:

1. You make sure they can't break it.
2. You make sure you can fix it much quicker than they can break it.

For the first one you could consider a recent Linux distribution that comes with a very tight set of SELinux rules. Given the fact that these students have to learn I would expect them to run into issues (like: you're not allowed to listen to a network port) that make it impossible to them to complete their assignments or simply go beyond their current skill level.

The second option is actually much more robust to realize.

1. Install something like cobbler to automate re-installation the system they work on.
2. Teach the students to commit their code to a subversion/git repository on a regular basis (usefull programming skill!!). Give the teacher access to the students repository. The students can simply ask the teacher to review a specific tag in their personal subversion.
3. Place all login information into an LDAP and configure your server to automagically create the home directory of the student when they log in.
4. Reinstall the server EVERY night. This is easy because you;ve automated the entire process.

Side effects:

• No malicious software lives longer than 24 hours.
• If the number of students grow you can simply add a second/third system and install it 100% identically.
• Any configuration problems are fixed once and stay fixed after the reinstallation.
• Students WILL forget to commit and lose work once in a while.

Answer 3

First, make sure to set up backups and learn how to restore the system.

That said, as long as you apply security updates without further delay (you can also check out unattended-upgrades), you should be fine. (Though if you can restrict external logins, e.g. only allowing key based authentication, you'll lower the risk further).

You'll want quotas and ulimit as suggested as well as monitoring (it's far more likely you'll suddenly run out of disk and people will be upset because of that than anyone knowledgeable enough to gain root access trashes it).

You don't want to start messing around with permissions (without knowing exactly what you're doing).

Answer 4

What about setting up user mode linux with a copy on write file in each student's home directory? This sandbox would give each one totally free reign on their own instance. If something breaks, simply chuck the COW file and you'll be back to the starting point.

scp/sftp could be used to upload submitted work to a central repository.