Re: Read-only root (/) except /etc
On Sun, Apr 13, 2008 at 05:32:22PM +0000, Digby Tarvin wrote:
> n Sun, Apr 13, 2008 at 12:04:31PM -0400, Douglas A. Tutty wrote:
> > On Sun, Apr 13, 2008 at 03:12:08PM +0000, lists2008@skaro.afraid.org wrote:
> >
> > > I don't *need* things read-only. I would just rather not *need* to
> > > have my root filesystem read write.
> > >
> > > I gave some reasons above for why I would like to be able to crontrol
> > > if and when the root filesystem is subject to writes..
> >
> > However, consider: as things stand now, only root can alter files which
> > don't have write permissions for others. Sure, if the filesystem were
> > mounted ro then root couldn't write to the files either (or delete
> > files). However, root could always remount / rw. Therefore there is no
> > security in a system once root is compromised whatever you do. If root
> > is not compromised, then standard unix permission scheme will provide
> > the security.
>
> The trouble is that isn't really true. As long as you have standard
> utilities like 'passwd' and 'chsh' normal users can cause the root
> filesystem to be modified any time they want..
No. The user isn't modifying anything really, its the suid utility
which is. User's don't have write permission on the /etc/passwd file.
The only security concern is if the suid utility is replaced by another;
in other words, again root is compromised.
> And in the examples I gave (running root off a DVD or drive with
> hardware write protect), a remount rw will only succeed in getting
> write failures logged....
So root turns off logging to. If we're talking about running off a DVD
then this is a LiveCD scenario with union mounting.
> But it isn't just security. It is another file system needing regular
> backup, and fewer writes means less likelihood of corruption eg if power
> goes off at the wrong instant..
Well sure, that makes sense. However, the only part that needs the
backup is /etc/ anyway, which would need backup if it was separate, so
no gain there.
As for e.g. corruption, I'd suggest having a duplicate root filesystem
taken care of by a script (which checks somehow that all is well) which
rsyncs them. This second root fs would be on its own partition with its
own entry in the boot loader. This suggests that /boot is on its own
partition and it is very easy to have /boot ro.
> The files that are a problem are the ones where either a change can
> result from user activity (passwrd/shadow) or where they are changed
> by demons, such as resolv.conf. I don't mind explicit changes by the
> administrator, who can take care or write-protects or reburning media.
I'd suggest to approach it as a live CD thingy, its a well tried path.
Anything else is frought with dragons.
Doug.
Reply to: