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]"

Reply via email to