Re: Read-only root (/) except /et
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Digby Tarvin wrote:
> On Sun, Apr 13, 2008 at 07:30:55PM -0400, Douglas A. Tutty wrote:
> <snip>
>>> 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.
>
> Well sure, when a user modifies somethign it always boils down to a progrma
> doing it on the users behalf. The important point is that the user can
> invoke such a change at any time. The suid file only restricts the nature
> of the chance.
>
> That means that in a standard config the root filesystem cannot be made
> read-only without braeaking things, preventing one possible security
> enhancing stategy.
>
>>> 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.
>
> so the worst case is a remount gains an infiltrator nothing if the filesystem
> non-writeability is enforced via hardware.
>
> And yes, I think a LiveCD is a very good example of the sort of hoops
> you have to jump through to have some of the root filesystem content
> run off read-only media.
>
>>> 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.
>
> The /etc on a separate filesystem was the suggestion of the original
> poster. Its not a solution that achieves my ideal of having only one
> system and one user filesystem that have to be read/write.
>
>> 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.
>
> Exactly what I am doing now on my bsd system:
> skaro:/usr/home/digbyt> mount
> /dev/wd0a on / (NFS exported, local)
> /dev/wd0h on /usr (NFS exported, local, read-only)
> /dev/wd0g on /var (local)
> /dev/wd0f on /usr/local (NFS exported, local, nodev, read-only)
> /dev/wd0e on /usr/home (NFS exported, local)
> /dev/wd0d on /user1 (local, nodev, nosuid, read-only)
> /dev/wd1h on /backup/usr (local, nodev, nosuid, read-only)
> /dev/wd1f on /backup/local (local, nodev, nosuid, read-only)
> /dev/wd1d on /backup/user1 (local, nodev, nosuid, read-only)
> localhost:/cfs/null on /cfs/crypt
> /dev/wd1a on /backup/root (local, nodev, nosuid, read-only)
> /dev/wd1g on /backup/var (local, nodev, nosuid, read-only)
> /dev/wd1e on /backup/home (local, nodev, nosuid, read-only)
>
> Note that all my live partitions are rsync'd with identical
> partitions on the backup disk every night, and by default all
> except home, var and root are read-only. The backup scripts
> know that they only have to backup live partitions that are
> read-write, and to remount the backup filesystems read-write
> during the procedure. If I do need to chance something on, for
> example, /usr/local, I remount it and leave it read/write. The
> backup scripts will see that it is r/w, back it up, and then make
> it read-only again when they finish so that it won't be backed
> up again till I repeat the process. User1 lets me arhive static
> user files in a way that leaves them accessible without making
> work for the backup scripts.
>
> If it were not for root, then there would
> be no writeable filesystem with suid and dev enabled.
> And of course if root could be mounted read-only, that would be one less
> filesystem that needed to be scanned for differences every night.
>
> There is also a big saving in boot time if there is a crash, because
> only filesystems mounted r/w will be dirty and need preening.
>
>>> 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.
>
> Sure. I didn't mean to hijack the topic. Its just something I have
> thought about and experimented with, so wanted to add my 2p worth to
> the original posters suggestion/query.
>
> Regards,
> DigbyT
>
>
It seems you want to install *BSD and just flag most of your
configuration nochg.
Regards
Rich
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIArpzLeTfO4yBSAcRAnUFAJ9f48h4ovhOBAyne2cIYZYp2aRFmgCfTk8V
2+Y7mA7toL9fP6kfBxDIi3k=
=2LZE
-----END PGP SIGNATURE-----
Reply to: