Running with a readonly root partition
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? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Running with a readonly root partition
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 Am Freitag, den 13.06.2008, 14:47 -0300 schrieb 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? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Running with a readonly root partition
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. 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. 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. My questions are: - does anyone else do this? no that - but i do this on my liveDVD - 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! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Running with a readonly root partition
On Fri, 13 Jun 2008, Mister Olli wrote: 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. I have some questions too: - 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. - 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. - 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. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
