An introductory C++ course is offered every year in our university. In order for students to code in C++ and submit their assignments, we give them shell access to a Linux server. They use ssh to log in to the server with their accounts, do the coding and keep the compiled code in their home directories. However, giving shell access brings in a number of vulnerabilities with it. My question is, Is there any other way, apart from giving shell access to students, in which we can fulfil the above mentioned purpose? Any server side tool/application that can provide an interface to students for doing their c++ assignments without compromising server security?
What you need is relatively simple: you need to ensure that your students' unprivileged accounts are well confined. If you don't have a graphical environment involved, your situation is relatively simple. You should start by implementing the following actions:
- ensure users are created without administrative privileges (no
- ensure users are unable to emulate a login screen to spoof your login screen (a classic for university, which I've seen happen)
- ensure proper
polkitdpolicy which prevents users from suspending/shutting down the host
- ensure you don't run vulnerable/outdated
sgidservices on the host (see how to list them)
- ensure no individual user can deplete the resources of the system (by configuring Systemd.cgroup to impose resource usage limits on the entire session of each user)
- strengthen your mandatory access control by installing and configuring properly SELinux (to limit students to a student role where they can only write in their home and in /tmp)
- expire accounts when necessary to avoid lingering accounts with eventually compromised passwords (see this question on the Unix site)
- you can even run students' sessions in separate containers using Systemd.nspawn which is designed to run fully working systems independently from one another, using Linux namespaces. This is the proper way to jail a session, not
You might then notice that students use the machines for other purposes than those allowed. You can limit access to machines to specific times using
pam_time though that might get in the way of students getting their work done and should be balanced against the benefits it provides. Also, make sure that your network administrators know what traffic to expect on this host so they can detect undesirable traffic.
All of this being said, I don't see the point in white-listing specific binaries (useless since students can compile and run their own code) as it may get in the way of students using legitimate development tools, e.g. alternative compilers, building toolchains, code analysis tools, code versioning tools, etc.
As long as users can only harm themselves and you've got strong guarantees of that, the job is done. This isn't exactly a long-term production system anyway, students are only using it to fool around with educational code.
It's far from complete, but a group of teammates from my University are developing Mumuki. The English version
seems to be broken doesn't have English content at the moment, but you can read it's intention there. You can also join the project and make it run C++ (I've started with C).
The idea of the platform is to create exercises with unit tests that check them.
We have started thinking about how to run the code in isolated ways, but up to now there's nothing implemented.
Yes there are. For a start, it's not a bad idea to use SSH but to improve security you can do the following:
- Use chroot jails to lock all 'student' users who log in via SSH into a limited environment.
- Do not give them sudo access, instead use specific scripts / commands in the sudoers list to allow a limited subset of the administration commands.
- Make the server not publicly accessible on any port > 1024. (run ssh on a high port number to prevent script-kiddie access).
- While you're at it, encourage them to use ssh-keys to log in. These are from a security standpoint far superior to username / password access (provided there encrypted with a password).
- As an alternative you could use git and continuous integration for this. (Gitlab and Jenkins combo for example) this has the added bonus of being able to only give them access through a safe web environment (when you use a TLS setup so 'https',use a proper certificate!) And all access is auditable.
Yes, there are alternative approaches. However, I think your question is based on flawed assumptions. While allowing shell logins to more people will obviously have security impacts, it doesn't necessarily mean by definition that the security of the resulting system cannot be effectively managed. These systems are designed to be multi-user systems and have the facility to manage this access in ways which will not compromise security (or at least, manage the level of risk to an acceptable point). The real challenge in these envrionments is that you typically don't have the resources to do this. For example, it is unlikely that a single student profile would be adequate - you would need profiles to reflect the different needs. An introductory programming course probably doesn't need the same access as a course on network programming or systems programming. The problem then becomes one of having sufficient time to administer all these different profiles and ensure they are appropriate.
Having said all that, I do think in this day and age, there are alternative approaches which are likely to be both more manageable and more appropriate. For example, using virtual machines can be very productive. These can be setup so that each student is isolated from each other and can be done so that they can 'refresh' their virtual environment to a known 'good state'. Then there are solutions based around things like Docker or Vagrant, which can be used to allow students to create a standard and consistent environment on their own machines. Instead of your server being a platform which students log into to do their work, your server becomes a distribution mechanism which allows the students to download a working environment which they can run themselves. This also allows the possibility of creating customised environments which have been tweaked to suit the specific course requirements.