From: Stanislav Ievlev <inger@altlinux.ru>
Subject: Re: /etc protection
Date: Thu, 23 Aug 2001 17:25:47 +0400
Next Article (by Date): Re: 2.4.9 etc. Amon Ott
Previous Article (by Date): RE: 2.4.9 etc. "Kaladis"
Top of Thread: Re: /etc protection steve
Next in Thread: Re: /etc protection David Ford
Articles sorted by: [Date]
[Author]
[Subject]
--------------090104090003040304070001 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jesse Pollard wrote: >--------- 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. > See "-n " options for mount/umount > > >>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. > >. > --------------090104090003040304070001 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <html> <head> </head> <body> Jesse Pollard wrote:<br> <blockquote type="cite" cite="mid:200108231244.HAA59390@mail.navo.hpc.mil"> <pre wrap="">--------- Received message begins Here ---------<br><br></pre> <blockquote type="cite"> <pre wrap=""><br>The biggest problem with the /etc is /etc/mtab. If You can't write it,<br>then mount won't work.<br><br>So what? Under RC protection If you set special fd type on /etc, you have<br>to exclude /etc/mtab from that. This won't work since it will delete this<br>file and then recreate, so the special fd attribute is lost.<br>If you set the special fd on every file in the /etc dir, hm.. nice job..<br><br>So the simplest solution is to remove /etc/mtab, and simply symlink to<br>/proc/mounts.<br>rm /etc/mtab<br>ln -s /proc/mounts /etc/mtab<br></pre> </blockquote> <pre wrap=""><!----><br>I think you also have to modify mount/umount to not write into it.</pre> </blockquote> See "-n " options for mount/umount<br> <blockquote type="cite" cite="mid:200108231244.HAA59390@mail.navo.hpc.mil"> <pre wrap=""><br><br></pre> <blockquote type="cite"> <pre wrap="">So if the /etc is read only, the system can start up. Of course you can<br>have problems with adjtime and so on, but these are not so critical<br>errors.<br></pre> </blockquote> <pre wrap=""><!----><br>not quite. You also must decide what services you are going to have:<br><br>The passwd utility attempts to update the shadow file there.<br><br>password, group files are updated when adding users/group (use NIS ?).<br><br>/dev/random and /dev/urandom maintenance procedures save state there (that<br>should be relatively easy to deal with though).<br><br>sshd maintains random sequences there. (Rebuild to put it somewhere else)<br><br>ntpd maintains clock skew data there (change config to point somewhere else)<br><br>ld.so.cache is located there (and is usually rebuilt on every boot).<br><br>ftp control files are there (might be considered static)<br><br>enabling/disabling services via System V (RH chkconfig utility) state is<br>maintained there.<br><br>Most of these should be able to be dealt with, just that there are other<br>things out there that may bite.<br><br>There should be a HOWTO on a read-only root file system. This may provide<br>addit ional pointers for side effects of making /etc read only.<br><br>-<br>To unsubscribe from the rsbac list, send a mail to<br><a class="moz-txt-link-abbreviated" href="mailto:majordomo@rsbac.org">majordomo@rsbac.org</a> with<br>unsubscribe rsbac<br>as single line in the body.<br><br>.<br><br></pre> </blockquote> <br> <br> </body> </html> --------------090104090003040304070001-- - 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 Date): Re: 2.4.9 etc. Amon Ott
Previous Article (by Date): RE: 2.4.9 etc. "Kaladis"
Top of Thread: Re: /etc protection steve
Next in Thread: Re: /etc protection David Ford
Articles sorted by: [Date]
[Author]
[Subject]