On Fri, May 9, 2014 at 10:32 AM, Theodore Ts'o <tytso@xxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
