Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
up vote 5 down vote accepted

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.

share|improve this answer
Adding to Cian's answer, I would also recommend isolating the box from a network perspective. If there is something compromised on the box, you don't want it in an area of the network where they could access any sensitive internal data. In our case we have a "students" VLAN, and anything that has shell and is student facing goes in that VLAN. That VLAN then has no other access to any other network. – Alex Sep 3 '09 at 12:09
How about adding something like Tripwire...that way you have checksums of files so you can have a record of what, if anything, is altered by outside users? – Bart Silverstrim Sep 3 '09 at 12:14

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.
share|improve this answer
This only works if it's to be used purely as a dev box, and users never want anything that you don't have installed. I've found that users invariably end up compiling stuff in their home dir, and heavily customizing their various . files, making reinstall every night unusable. – Cian Sep 3 '09 at 10:28
Yep, you're absolutely right. It's always good to check all possible solutions to see if such a solution can work in the specific situation at hand. Given the fact that there are only students doing assignments the teacher dictates the required tools. Any additional usefull tooling can be added to the reinstall script. – Niels Basjes Sep 3 '09 at 11:01
You're still not going to deal with user's config files. Most users quickly end up with bash/vim/$OTHER_THING rcs, which you're wiping every night. If my university had set up a service like that, I'd have just not used it, given the amount of pita it'd be to copy over my . files every morning. – Cian Sep 3 '09 at 11:30
seperating a home partition and keeping it intact would solve that issue. – hayalci Sep 3 '09 at 12:15

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).

share|improve this answer
Allowing only key based logins for a general student login machine is far, far more of a pita than it's worth, ime. – Cian Sep 3 '09 at 9:00

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.