Re: immutable files via O_OBJECT

[Colin Walters <walters@verbum.org>]

On Fri, May 9, 2014 at 10:32 AM, Theodore Ts'o <tytso@mit.edu> wrote:
> 
> What's the security properties that this would buy you over simply
> doing something like this?
> 
>        fchmod(fd, 0444);

Unfortunately for root-owned processes they'll often have 
CAP_DAC_OVERRIDE which makes the mode irrelevant.

For example, we have the scenario of an admin at a bash shell, either 
accidentally changing /usr or perhaps they try to run an install 
script.  A concrete example of this is on the net you'll find people 
trying to "vi /usr/lib/systemd/system/foo.service" to change 
configuration, but that's not supported.

Now the read-only bind mount generally puts a stop to this, but I'd 
like an even stronger guarantee.

The other scenario that I've been worrying about is admins doing 
something like "restorecon -R /", which will traverse /sysroot out to 
the physical root, and potentially break the SELinux labels.  It would 
work for me to also freeze xattrs, but it'd be a bit weird as the whole 
point of xattrs is to be extended metadata.  Perhaps this one is best 
fixed in userspace.

> Sure, root (or the owner) could change the always change the
> permissions on the file --- but root can always modify the file by
> opening the block device directly using a tool like debugfs.  

Yeah, of course.  However this is much harder to achieve, both by 
admins at a shell doing it accidentally, and access to raw block 
devices will typically be more carefully secured by things like SELinux.

> So if
> you need to guarantee that the object hasn't changed, you're going to
> have to you a cryptographic checksum, or such as what git does.

OSTree does have a SHA256 checksum, but it'd be better to avoid files 
being mutated in the first place.

> I suppose the one benefit is that you could have a file which is owned
> by some uid other than root, and still have some form of immutability
> guarantees, which might be useful if you need the uid for (a) quota
> purposes, (b) setuid/setgid purposes, and (c) so that a non-root user
> can create one of these objects.

This does occur for me because I have /usr/etc which has non-root owned 
files (e.g. /usr/etc/polkit-1), but is intended to be a read-only copy.

Another case is dconf, which writes out a mmap-able file of settings 
that's read by many processes, but only written by one daemon, and when 
it does, it does the "write tmpfile, fsync, rename()" dance.  That 
would be O_OBJECT as well.  (Maybe O_IMMUTABLE_OBJECT for clarity).

> But in order to do this, we would have to plumb through glibc, VFS,
> and low-level file system changes for a non-portable feature that
> would only be useful in Linux systems.  Is it really worth it?

Maybe not; I think it's an interesting discussion at least.  Did you 
have any reply on the potential performance improvements?  We could 
even extend the concept to directories - I want to lay down a set of 
immutable files, then close the directory and have that be immutable 
too.