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