Re: Read-only root (/) except /et
- From: "Digby Tarvin" <lists2008@xxxxxxxxxxxxxxxx>
- Date: Mon, 14 Apr 2008 01:41:12 +0000 (GMT)
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 debian-user-REQUEST@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx
- Follow-Ups:
- Re: Read-only root (/) except /et
- From: Rich Healey
- Re: Read-only root (/) except /et
- Prev by Date: Kernel source packages..
- Next by Date: Re: Read-only root (/) except /et
- Previous by thread: Kernel source packages..
- Next by thread: Re: Read-only root (/) except /et
- Index(es):
Relevant Pages
|
