The Linux Student Development Server: Part 1
A few weeks ago I was tasked with establishing a *nix based server at work for the purposes of development access (first year Unix and C Students).
Up front this sounds fairly simple (install a distro, openssh, install the dev tools, create accounts, voila) but in practice there are a number of other considerations which makes the task somewhat more involved. Now I’ve set up plenty of linux boxes before, but this will be one of the few intended for general use by a number of unknown people – eg not simply for access by a small number of trusted admin only.
Firstly, as this box is to be shell-accessible by students, it needs to be as idiot-proof as possible while still allowing reasonable access to a development environment. This means limitations on runaway forks, inode creation, et cetera.
This machine will need to authenticate and create users based on pre-existing groups in the Active Directory. As we do not have schema access there will be no installation of extensions to the AD for unix support. I am personally against this approach anyway: For simple authentication of users, directly modifying the AD schema seems excessive.
Security is also another fairly prominent concern : I am well aware that once a potentially malicious (or simply curious) user has access to a local account, without appropriate countermeasures and vigilance by the keepers of root, a security breach is quite likely. One of the core study streams at the School of Computer and Information Science where I work is Computer and Network Security: consequently we have a number of potential users fairly au-fait in that area: so adequate security on a system they will be accessing is quite important.
Security concerns currently on my list:
- Preventing local system exploits
- Constraining system resource abuse
- Preventing unauthorised network access*
* As this machine will have internet access outside the firewall scope of other networks accessible to the students (wireless, computer labs etc) an important consideration is preventing its use to circumvent network access restrictions (for example via a userland proxy or chat bot, or unrestricted SMTP). As the development machine is located in a secure DMZ, compromise from the outside due to an insecure listening process of some kind started either accidentally or maliciously by a user is of less concern to interneal network security in general, but measures should still be taken to prevent this sort of thing.
For the time being, no X environment is required, which will save me some work in the short term until I can look at it later in the ‘optional extras’ category.
Items on the agenda to setup:
- User Authentication and auto local account / home directory creation via Active Directory
- C dev environment
- Tomcat based java dev environment
- Access via: SSH, FTP, HTTP, SMB (latter 2 with intelligently mapped user paths)
- Local system firewalling according to security policy
- Auditing of local user logins
- Tripwire integrity auditing
- Backups of config, tripwire db, user homes, and MSQL db to active directory based server
In Part 2 I will cover a few of the items in the list including User Auth via AD, C Dev environment, SSH setup, and any incidentals I encountered along the way.
