immutable files via O_OBJECT

immutable files via O_OBJECT

[Colin Walters]

Hi,

I'm the author of https://live.gnome.org/Projects/OSTree which is a new 
general purpose update system for Linux-based operating systems.

Basically it does updates by creating a new hardlink farm chroot. 
(There's nothing really new about this, OSTree is just a polished 
version of it with a new twist or two)

Now present, I have a read-only bind mount over /usr. What I'd really 
like is something like the existing S_IMMUTABLE bit except with the 
ability to make hardlinks.  Also unlike S_IMMUTABLE I don't want it to 
be removable at all.

And the more I thought about it, the more I realized what would be neat 
is a new open flag "O_OBJECT". What this would do is disallow any 
further changes to content after the file has been close()d or so.

(It would also be nice to have a way to make xattrs immutable, but I 
see that as a separate thing)

I can imagine that beyond the security aspect, filesystems could make 
some interesting optimizations if userspace opted out of the ability to 
mutate files post-creation.

Both OSTree and git could use it (git for loose objects).

There's been stuff somewhat related to this in the past, like 
linux-vserver was carrying a hack to do CoW hardlinks. But I think it's 
really better to just disallow mutation and force userspace to break 
hardlinks.

If you guys give me this flag, I'll make use of it in userspace pretty 
much right away =)

Re: immutable files via O_OBJECT

[Theodore Ts'o]

On Fri, May 09, 2014 at 10:10:22AM +0000, Colin Walters wrote:
> 
> And the more I thought about it, the more I realized what would be neat is a
> new open flag "O_OBJECT". What this would do is disallow any further changes
> to content after the file has been close()d or so.

What's the security properties that this would buy you over simply
doing something like this?

       fchmod(fd, 0444);

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

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.

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?

      	      	     	      		- Ted

Re: immutable files via O_OBJECT

[Colin Walters]

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.