-----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----- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]