Running with a readonly root partition

[A. Hamilton-Wright]

As devfs is running by default, it seems to me that
it would be relatively easy to run with a readonly
root partition, assuming that the directories under
which writing is necessary (ie; /tmp, /var, /home)
are located in separate, writable partitions.

The main advantages are that none of the configuration
files or binaries in /etc and /usr (which may still
be on a separate readonly partition) are vulnerable
to attack (even from a local privilege escalation)
without remounting the partition as writable.

This used to be a very common setup in the *NIX
world, so I am surprised to find little to no mention
of it in the archives.

I set up my machine this way a couple of months back,
and have noticed some minor things (some few things
assume a writable /etc, notably including dump(8),
and the boot process update to /etc/motd). Once these
have been rectified by relocating the files and setting
up symlinks, there have been no problems.

My questions are:
- does anyone else do this?
- if not, why not?

[Mister Olli]

hi...

do you have some kind of installation/setup manual?
that would be really interesting to see your steps, and try that myself.

I have some questions too:
- how do you handle updates/ installation of new software?
- how do you prevent someone who hacked the machine to remount '/' as
writable
- how do users update theirs passwords when '/etc' is read-only?


greetz
olli

Post by A. Hamilton-Wright
As devfs is running by default, it seems to me that
it would be relatively easy to run with a readonly
root partition, assuming that the directories under
which writing is necessary (ie; /tmp, /var, /home)
are located in separate, writable partitions.
The main advantages are that none of the configuration
files or binaries in /etc and /usr (which may still
be on a separate readonly partition) are vulnerable
to attack (even from a local privilege escalation)
without remounting the partition as writable.
This used to be a very common setup in the *NIX
world, so I am surprised to find little to no mention
of it in the archives.
I set up my machine this way a couple of months back,
and have noticed some minor things (some few things
assume a writable /etc, notably including dump(8),
and the boot process update to /etc/motd). Once these
have been rectified by relocating the files and setting
up symlinks, there have been no problems.
- does anyone else do this?
- if not, why not?
_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-questions

[Andrew Wright]

Post by Mister Olli
do you have some kind of installation/setup manual?
that would be really interesting to see your steps, and try that myself.

There aren't very many steps:
- install as per normal, but with the following on separate
partitions: /, /tmp, /var
Most people usually put /usr on a separate partition too,
as it makes software updates easier

DO NOT put /etc on a separate partition, or you will have
an unbootable system

- make a directory /var/etc (or other similar location in the
writable portion of your filesystem)

- copy the necessary files to /var/etc and create symlinks
in /etc of the form ../var/etc/<filename>
The files I have done this for are dumpdates and motd
Other files may be required if you run other daemons;
I experimented with denyhosts, and therefore had
hosts.allow there for a while

- update /etc/fstab to have 'ro' instead of 'rw' for / and /usr

- reboot or run
mount -u -r / ; mount -u -r /usr

if you want to test whether things are working, just run
mount and see whether things are ok for a while before
updating /etc/fstab -- then any major panics can be solved
with a reboot.

Post by Mister Olli
- how do you handle updates/ installation of new software?

By remounting before doing updates. I don't do updates
that often, so this is not a problem for me.

Post by Mister Olli
- how do you prevent someone who hacked the machine to remount '/' as
writable

You don't; at least not this simply. The main advantages of
this strategy are protection against (a) accidental changes
by root users and (b) trojans, scripts and other naive rootkits.

Like most security ideas, it is simply a single step along the
way, and the usual rule applies -- anyone who actually has root
has the privileges to damage the system to any extent they like.

Post by Mister Olli
- how do users update theirs passwords when '/etc' is read-only?

This is a larger problem, and one I had forgotten about as the
machine in question is a firewall/datashare that doesn't have
many users. Things should work fine if you are running yp
or similar from another machine; alternatively a password
update script can be written to either (a) do the remount to
allow updating on the fly, or (b) queue the update until a
regular remount+update cycle (as many large shops do).

Certainly not a one-size fits all solution for everyone, but
I remain curious as to why this technique has fallen out of
favour. Perhaps it is this weakness with local passwords that
has caused most people to give up the (relatively small)
security advantages in favour of simplicity?

Andrew.

[Wojciech Puchar]

Post by A. Hamilton-Wright
As devfs is running by default, it seems to me that
it would be relatively easy to run with a readonly
root partition, assuming that the directories under
which writing is necessary (ie; /tmp, /var, /home)
are located in separate, writable partitions.

yes.

Post by A. Hamilton-Wright
The main advantages are that none of the configuration
files or binaries in /etc and /usr (which may still

/etc is rather writable - for example when user changes password.

Post by A. Hamilton-Wright
be on a separate readonly partition) are vulnerable
and the boot process update to /etc/motd). Once these
have been rectified by relocating the files and setting
up symlinks, there have been no problems.
- does anyone else do this?

no that - but i do this on my liveDVD

Post by A. Hamilton-Wright
- if not, why not?

if you will set securelevel to prevent umounts - it may add much to the
security.

but - the same time - you'll have to reboot system to change anything!