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 =)

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Theodore Ts'o]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Colin Walters]

Post by Theodore Ts'o
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.

Post by Theodore Ts'o
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.

Post by Theodore Ts'o
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.

Post by Theodore Ts'o
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).

Post by Theodore Ts'o
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.



--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html