From mboxrd@z Thu Jan 1 00:00:00 1970 From: Colin Walters Subject: Re: immutable files via O_OBJECT Date: Fri, 09 May 2014 15:12:36 +0000 Message-ID: <1399648596.2647.0@mail.messagingengine.com> References: <1399630462.17314.3@mail.messagingengine.com> <20140509143245.GA15523@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Cc: Linux-Fsdevel To: Theodore Ts'o Return-path: Received: from out5-smtp.messagingengine.com ([66.111.4.29]:41567 "EHLO out5-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753587AbaEIPQi (ORCPT ); Fri, 9 May 2014 11:16:38 -0400 Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 5E77721CF1 for ; Fri, 9 May 2014 11:16:38 -0400 (EDT) In-Reply-To: <20140509143245.GA15523@thunk.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, May 9, 2014 at 10:32 AM, Theodore Ts'o 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.