Handling labeling on filesystems that don't support SELinux

[Stephen Smalley]

On Mon, 2008-11-17 at 11:16 -0500, Sean E. Millichamp wrote:
> Hmm... I believe that checking for an error at assignment time is not
> going to be a workable solution for Puppet.
> 
> The problem is that Puppet prepares what it needs to do in a transaction
> before doing it.  Take the situation where /usr/local is NFS mounted:
> 
> # ls -Z /usr/local/bin/foo
> -rwxr-xr-x  root root system_u:object_r:nfs_t:s0       /usr/local/bin/foo
> # matchpathcon /usr/local/bin/foo
> /usr/local/bin/foo	system_u:object_r:bin_t:s0
> 
> Then you run puppet with a manifest that includes management
> of /usr/local/bin/foo.

Can you explain what it means for puppet to manage a NFS-mounted
filesystem?  I'd tend to think that file management would happen on the
server, not on a client.  And puppet could easily run into problems with
e.g. setting ownership/mode information on a NFS-mounted filesystem due
to squashroot, uid/gid remapping, etc.

>   The first thing Puppet does is determine default
> values.  For SELinux this means a call to matchpathcon.  Then Puppet
> determines the current values with lgetfilecon.  It notices that the
> default value for the type should be bin_t, but the current is nfs_t so
> it adds changing the type to its list of things to do.  As it is
> building this list it reports on the things it intends to do.
> 
> Once it determines all of the actions that it needs to take only then
> does it perform the setfilecon call to update the context.  Even if we
> catch and silently ignore the error here the logging for the steps it
> intends to take will occur on every single Puppet run, filling the logs
> with what amounts to garbage and making email reports of changes
> essentially useless (as you would get an email on every run telling you
> of the changes it was going to make).
> 
> Performing a setfilecon call to the same context that exists during the
> first phase to determine if a value can be set would be the only way I
> could see to handle this, but it violates Puppet's promise of not
> touching anything during a noop run and will update the ctime of the
> file.
> 
> In the case of filesystems which behave like vfat Puppet would set the
> label the first time following the mount and until it is remounted
> wouldn't generate any additional messages.  Filesystems which behave
> like NFS are the real problem case though and NFS is far more likely to
> be mounted at a spot where matchpathcon returns a default then (for
> example) vfat is.
> 
> I'm not a fan of hardcoding a whitelist of supported filesystems for the
> very reasons Dan mentioned but it sounds like there isn't a good option
> for Puppet at the moment (and since I couldn't find any better options,
> this is what is going into the next Puppet release).

Ok - that's essentially what Dan does in his /sbin/fixfiles script as
well.

>   No chance of
> seeing a "supports_setfilecon" type call?

Possibly an interface could be added to selinuxfs and wrapped with a
libselinux function of that nature.

Or possibly we could export that via a new mount option that shows up
in /proc/mounts since we now support exporting information about context
mounts there?  There are already mount options for user_xattr and acl
for example, but not explicitly for security contexts.

-- 
Stephen Smalley
National Security Agency