From: Jesse Pollard <pollard@mail.navo.hpc.mil>
Subject: Re: /etc protection
Date: Thu, 23 Aug 2001 07:44:16 -0500 (CDT)
Next Article (by Subject): Re: /etc protection Stanislav Ievlev
Previous Article (by Subject): Re: /etc protection Bencsath Boldizsar
Top of Thread: Re: /etc protection steve
Next in Thread: Re: /etc protection Stanislav Ievlev
Articles sorted by: [Date]
[Author]
[Subject]
--------- Received message begins Here --------- > > > The biggest problem with the /etc is /etc/mtab. If You can't write it, > then mount won't work. > > So what? Under RC protection If you set special fd type on /etc, you have > to exclude /etc/mtab from that. This won't work since it will delete this > file and then recreate, so the special fd attribute is lost. > If you set the special fd on every file in the /etc dir, hm.. nice job.. > > So the simplest solution is to remove /etc/mtab, and simply symlink to > /proc/mounts. > rm /etc/mtab > ln -s /proc/mounts /etc/mtab I think you also have to modify mount/umount to not write into it. > So if the /etc is read only, the system can start up. Of course you can > have problems with adjtime and so on, but these are not so critical > errors. not quite. You also must decide what services you are going to have: The passwd utility attempts to update the shadow file there. password, group files are updated when adding users/group (use NIS ?). /dev/random and /dev/urandom maintenance procedures save state there (that should be relatively easy to deal with though). sshd maintains random sequences there. (Rebuild to put it somewhere else) ntpd maintains clock skew data there (change config to point somewhere else) ld.so.cache is located there (and is usually rebuilt on every boot). ftp control files are there (might be considered static) enabling/disabling services via System V (RH chkconfig utility) state is maintained there. Most of these should be able to be dealt with, just that there are other things out there that may bite. There should be a HOWTO on a read-only root file system. This may provide additional pointers for side effects of making /etc read only. - To unsubscribe from the rsbac list, send a mail to majordomo@rsbac.org with unsubscribe rsbac as single line in the body.
Next Article (by Subject): Re: /etc protection Stanislav Ievlev
Previous Article (by Subject): Re: /etc protection Bencsath Boldizsar
Top of Thread: Re: /etc protection steve
Next in Thread: Re: /etc protection Stanislav Ievlev
Articles sorted by: [Date]
[Author]
[Subject]