> Why exactly do you need things read-only?
>
> Try the package flashybrid for a different approach to a similar
> problem.

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..

Running a flash based system is certainly one application that would be made easier by this.

flashybrid looks interesting for embedded applications. But I would really like to be able to flick on the hardware write protect switch on my root filesystem on a regular server and know that nothing will break.

DigbyT

> 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..

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….

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..

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.

DigbyT

> 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.

DigbyT

> Is it possible to have /etc on a separate partition from / (root) so
> that root can be read-only while /etc is read-write?

Making a read-only root-fs is quite complex. You didn't write why you do want to do this. If you have a medium that may break by to many writes (like a flash-disk), you can try mounting another (tmpfs?) over it with unionfs or aufs (I got better results with that). If you want to use that as a security feature, it won't work. If you really want read-only-root, you should have a log at grml-live [1]. Grml is a debian-based live-cd aimed for advanced users with a focus on text-tools (no kde, no ooo), and grml-live is its automated build-tool.

Timo

[1] http://www.grml.org/grml-live/