0

Is there a permanent and secure (as in integrity) way to make the entire Ubuntu system of a VPS (virtual private server) read-only to all users (including the root user)?

  • 1
    Does it need to prove cryptographic integrity to a remote party? I.e. if the VPS host itself was malicious or compromised, would you still need it to ensure integrity? Or do you merely want to prevent a root application from modifying anything on the filesystem? – forest Oct 20 '18 at 10:43
  • 1
    @TorinCarey A root user could still override that. OP would need to have the VPS boot from a read-only storage that is not controlled by the VPS (e.g. mark it as read-only from the level of the VPS host). – forest Oct 20 '18 at 10:46
  • 1
    @forest I meant for the underlying storage to be read-only rather than just mounting it as read-only, which is in-line with what you've said – Torin Oct 20 '18 at 10:48
  • 2
    @LucianNitescu Why not run a fresh instance of the VPS from a known-good template for each challenge? Having write access to the individual VPS would not be an issue if any changes vanish when the VPS is restarted. Would that solution be in-line with your requirements? – forest Oct 20 '18 at 10:51
  • 1
    I'm not sure how it would create any issues. The VPS should be easily restartable from the template. You could also have a writable template, but give each challenger their own writable template. That way they could not make any modifications that would affect other challengers. – forest Oct 20 '18 at 10:57
1

Yes, using Mandatory Access Control. It would be an awful lot of work, though.

Mandatory Access Control systems allow you to impose restrictions on actions, even those performed by root, and with the ability to be granular to the process (e.g. dhcpcd running as root can edit /etc/resolv.conf, but vi running as root cannot).

It's likely impossible to have a running Ubuntu system which is completely read-only. Various OS processes expect to be able to write to files (e.g., /bin/login wants to update utmp, btmp, wtmp; lots of things want to log). Of course, if you can figure out all those files, you can permit necessary access, but doing so is quite a chore.

The most commonly known MAC system is SELinux. To quote Wikipedia,

SELinux can potentially control which activities a system allows each user, process and daemon, with very precise specifications. It is used to confine daemons like database engines or web servers that have clearly defined data access and activity rights. This limits potential harm from a confined daemon that becomes compromised.

Which matches the goal you stated in the comments:

create an environment which is read-only in case of a buffer overflow (which will be given as a challenge).

Ubuntu uses AppArmor instead of SELinux.

MAC systems generally require "something special" to turn them off, such as rebooting into a special mode, which is not accessible to a remote attacker. (Obviously, if root can just "turn it off" easily, it doesn't protect against root.)

Allow me to repeat myself: doing this is an awful lot of work. Systems like SELinux can be prohibitively difficult to configure correctly; in general you will find them working in limited, targeted protection profiles (e.g., "don't let the web server get at stuff") and distributed in a tested, controlled configuration from an OS vendor (Red Hat does this, for example). If you want to use it to lock down everything, you've got a lot of work to do.

For what its worth, one of AppArmor's selling points is that it's easier than SELinux, so the fact that you're on Ubuntu may put the odds ever in your favor.

| improve this answer | |

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.