17

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?

  • 1
    Is it required that they code on the server? – RoraΖ May 22 '15 at 11:12
  • 12
    Have you considered using VMs to fully isolate the students from each other? Disk space, especially for relatively ephemeral data, is relatively cheap, and cloning a pre-provisioned VM can reduce the on-disk footprint, but 30+ VMs do need a reasonable chunk of RAM to work well. – a CVn May 22 '15 at 12:04
  • 14
    What makes you believe that "giving shell access brings in a number of vulnerabilities with it."? – Karalga May 22 '15 at 15:33
  • 3
    Why not just have them use Github or something of that nature? Source control is something they need to learn anyway. – Kevin Krumwiede May 22 '15 at 22:49
  • 1
    I don't think it would be appropriate for an entire course, but there are browser-based services like ideone.com that work pretty well if all you want to do is let people write some code and execute it. I've used ideone.com in a physics course where I had the students learn a tiny bit of python in order to do simple simulations. The advantage is that it requires zero setup or resources from me, and there is zero security risk. – Ben Crowell May 23 '15 at 13:36
29

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 sudo, no admin or wheel group)
  • 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 polkitd policy which prevents users from suspending/shutting down the host
  • ensure you don't run vulnerable/outdated suid/sgid services 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 chroot

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.

  • 3
    Your right that a Systemd.nspawn is better than a chroot, its just not available on all systems. chroot is on almost all. Security wise your awnser is better than my suggestion of chroot. It is however also a lot harder to setup (a lot more work). I believe my suggestion of just using a continous integration setup is even better. but is also a lot of work. – LvB May 22 '15 at 11:58
  • The problem with chroot is that if you want to chroot an entire session, you'll have to code support for that in your logind. – Steve Dodier-Lazaro May 22 '15 at 11:58
  • you do know that chroot support for that is inside openssh? or am I missing something? – LvB May 22 '15 at 12:00
  • 1
    Ah! I actually didn't! I would still prefer a container-based solution, as the goal of confining would be to prevent a privilege escalation that breaks the AC model of the system. User namespaces provide tangible protection against root privilege escalations (unlike chroot). – Steve Dodier-Lazaro May 22 '15 at 12:09
  • True that, its all about effort / protection balance that is needed. (OP needs to decide that) – LvB May 22 '15 at 12:15
3

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.

  • 1
    This seems harsh, but, in what way does that answer the question? The execution still isn't isolated and there is still no way to solve the O.P.'s issue. – Ismael Miguel May 22 '15 at 18:40
  • It's an application that provides an intrrface for students to upload their assignments without having ssh (part of what the OP is asking) and that doesn't solve the isolation at the moment but is intended to. – mgarciaisaia May 22 '15 at 18:51
  • @IsmaelMiguel: ie, it's not an out-of-the box solution at the moment, but the tool is intended exactly for what the user is trying to do. – mgarciaisaia May 22 '15 at 18:54
  • That's a pretty convincing argument. +1 on that! – Ismael Miguel May 22 '15 at 19:14
1

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.
  • 5
    encourage them to use ssh-keys no, don't encourage them. Force them. Make them learn good practices right from the beginning. They shouldn't even be given the possibility to get a passing grade if they can't bother respecting basic security practices. – user42178 May 22 '15 at 20:04
  • 1
    by encourage I anot also mean force, but also motivate them to use ssh-keys (so more than just forcing) – LvB May 22 '15 at 23:26
  • Where do you propose they will connect from? Lab machines on which they've already authenticated (then use ssh-keys)? Or do they connect via their own PCs/laptops? In the latter case, SSH keys will have a higher support cost because CS undergrads are quite good at bricking/reinstalling their OS ruthlessly and at changing computers. You'll have to spend time explaining them how to migrate their keys, or helping them add a newly made key to their authorized_keys. Keep in mind unis often have ~200 undergrads in a CS course, and academics are pretty busy people :-) – Steve Dodier-Lazaro May 23 '15 at 10:19
  • The students use both Lab PCs and their personal laptops; whatever is convenient for them. They just need to connect to the server and start working on their assignments. Each user is given a username which is the same as his/her university student ID – Soban May 23 '15 at 11:11
  • I guess learning how to backup is important... to learn sooner rather than later. – LvB May 24 '15 at 0:15
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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