From: Stanislav Ievlev <inger@altlinux.ru>
Subject: Re: /etc protection
Date: Thu, 23 Aug 2001 17:25:47 +0400
Next Article (by Subject): Re: /etc protection David Ford
Previous Article (by Subject): Re: /etc protection Jesse Pollard
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 Subject): Re: /etc protection David Ford
Previous Article (by Subject): Re: /etc protection Jesse Pollard
Top of Thread: Re: /etc protection steve
Next in Thread: Re: /etc protection David Ford
Articles sorted by: [Date]
[Author]
[Subject]