Handling labeling on filesystems that don't support SELinux

[Sean E. Millichamp]

I have been working on SELinux support for Puppet.  One issue that has
cropped up is the behavior on filesystems which don't support SELinux.

They all appear to get a default label, some seem to allow changing the
label (VFAT) in a non-persistent manner, some seem to throw "not
supported" errors (NFS).

How can I detect if a file is on a filesystem which supports SELinux
without trying to update the label?

The best idea so far as been to parse /proc/mounts and use that to
determine what type of filesystem a file lives on, then check it against
a whitelist (which would include ext3, xfs, ?) but it seems like there
has to be a cleaner/simpler way.

What I would like would be a "getfilecon" call that returns the real
label, ignoring any mount-time defaults.

Any ideas?

Thanks,
Sean

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sean E. Millichamp wrote:
>  I have been working on SELinux support for Puppet.  One issue that
> has
>  cropped up is the behavior on filesystems which don't support SELinux.
>  
>  They all appear to get a default label, some seem to allow changing the
>  label (VFAT) in a non-persistent manner, some seem to throw "not
>  supported" errors (NFS).
>  
>  How can I detect if a file is on a filesystem which supports SELinux
>  without trying to update the label?
>  
>  The best idea so far as been to parse /proc/mounts and use that to
>  determine what type of filesystem a file lives on, then check it against
>  a whitelist (which would include ext3, xfs, ?) but it seems like there
>  has to be a cleaner/simpler way.
>  
>  What I would like would be a "getfilecon" call that returns the real
>  label, ignoring any mount-time defaults.
>  
>  Any ideas?
>  
>  Thanks,
>  Sean
>  
>  
>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list 
I have been waiting for
some one else to respond to this.  I think this
would be better sent to the nsa selinux list for better discussion.

The problem with your parsing of the /proc/mounts is that it would not
give you an accurate idea of what supports and what does not support
SELinux labeling.  Also this can change over time.

If I mount an ext3 file system with a context mount, then it will no
longer allow you to set the file context.  I think the best idea is just
attempt to assign the context and if it fails, ignore the error.  I
guess you can report it, if in verbose mode as a warning.

Others may have different ideas.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkkhg4EACgkQrlYvE4MpobMPMgCgm+G/Pyrll2CKHUynWftA7Shq
> phMAnAwTXQQ+mQH33EjP20o9iM7gaVvE
> =eDjj
> -----END PGP SIGNATURE-----

[Stephen Smalley]

On Mon, 2008-11-17 at 09:45 -0500, Daniel J Walsh wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  Sean E. Millichamp wrote:
>  > I have been working on SELinux support for Puppet.  One issue that has
>  > cropped up is the behavior on filesystems which don't support SELinux.
>  > 
>  > They all appear to get a default label, some seem to allow changing the
>  > label (VFAT) in a non-persistent manner, some seem to throw "not
>  > supported" errors (NFS).
>  > 
>  > How can I detect if a file is on a filesystem which supports SELinux
>  > without trying to update the label?
>  > 
>  > The best idea so far as been to parse /proc/mounts and use that to
>  > determine what type of filesystem a file lives on, then check it against
>  > a whitelist (which would include ext3, xfs, ?) but it seems like there
>  > has to be a cleaner/simpler way.
>  > 
>  > What I would like would be a "getfilecon" call that returns the real
>  > label, ignoring any mount-time defaults.
>  > 
>  > Any ideas?
>  > 
>  > Thanks,
>  > Sean
>  > 
>  >  
>  I have been waiting for some one else to respond to this.  I think
> this
>  would be better sent to the nsa selinux list for better discussion.
>  
>  The problem with your parsing of the /proc/mounts is that it would not
>  give you an accurate idea of what supports and what does not support
>  SELinux labeling.  Also this can change over time.
>  
>  If I mount an ext3 file system with a context mount, then it will no
>  longer allow you to set the file context.  I think the best idea is just
>  attempt to assign the context and if it fails, ignore the error.  I
>  guess you can report it, if in verbose mode as a warning.
>  
>  Others may have different ideas. 
You'd want to distinguish EOPNOTSUPP from other errors in that case.
But note that this won't catch certain filesystems (like the vfat
example he gave), as changing the in-core context of a file labeled via
genfscon rules is supported presently.  We could possibly change that to
also return EOPNOTSUPP.

The problem with using getfilecon() to probe for support is that SELinux
always assigns some security context to each file for access control
purposes, even if the underlying filesystem doesn't support storage.  If
we had separate getfilecon() vs. getxattr() kernel interface ala
FreeBSD, applications could test for support for storage separately, but
that isn't the case and is unlikely to change.

-- 
Stephen Smalley
National Security Agency

[Sean E. Millichamp]

On Mon, 2008-11-17 at 10:26 -0500, Stephen Smalley wrote:
>  On Mon, 2008-11-17 at 09:45 -0500, Daniel J Walsh wrote:
>  > I have been waiting for some one else to respond to this.  I think this
>  > would be better sent to the nsa selinux list for better discussion.
>  > 
>  > The problem with your parsing of the /proc/mounts is that it would not
>  > give you an accurate idea of what supports and what does not support
>  > SELinux labeling.  Also this can change over time.
>  > 
>  > If I mount an ext3 file system with a context mount, then it will no
>  > longer allow you to set the file context.  I think the best idea is just
>  > attempt to assign the context and if it fails, ignore the error.  I
>  > guess you can report it, if in verbose mode as a warning.
>  > 
>  > Others may have different ideas.
>  
>  You'd want to distinguish EOPNOTSUPP from other errors in that case.
>  But note that this won't catch certain filesystems (like the vfat
>  example he gave), as changing the in-core context of a file labeled via
>  genfscon rules is supported presently.  We could possibly change that to
>  also return EOPNOTSUPP.
>  
>  The problem with using getfilecon() to probe for support is that SELinux
>  always assigns some security context to each file for access control
>  purposes, even if the underlying filesystem doesn't support storage.  If
>  we had separate getfilecon() vs. getxattr() kernel interface ala
>  FreeBSD, applications could test for support for storage separately, but
>  that isn't the case and is unlikely to change. 
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.  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).  No chance of
seeing a "supports_setfilecon" type call?

Sean

[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

[Sean E. Millichamp]

On Mon, 2008-11-17 at 11:34 -0500, Stephen Smalley wrote:

>  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. 
Managing a file essentially means "ensure the existence/absence of a
file/directory, its ownership/permissions, and contents".  The first use
case that pops to mind is for NFS servers where you can't run Puppet on
the server itself (an appliance device).  Then you would need to manage
the files from one or more clients.

The big difference between SELinux contexts and the other attributes is
that in the absence of uid/gid/mode being explicitly specified Puppet
sees the default as "nil".  This causes Puppet to ignore those
attributes and, if creating a file, will just default to the umask/user
that Puppet is running with.  With SELinux the proper way to determine
the default is to ask matchpathcon - so for any file where the user
doesn't explicitly specify a context but matchpathcon returns one there
is a non-nil default, causing Puppet to try to make the file in-sync if
the actual doesn't match it.  If an NFS filesystem was mounted
at /mnt/nfs on my Fedora 9 system matchpathcon won't return a default
for /mnt/nfs/foo so Puppet won't trigger any SELinux actions (unless the
user explicitly lists a context).

>  > 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. 
Ah, I just skimmed the script.  I feel much better about this approach
now and it will hopefully suffice.  Also, since the whitelist exclusion
is only for determining defaults, a user that wanted to actively manage
an SELinux context could still explicitly list it in the file attributes
and Puppet will try to set it regardless.

>  >   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. 
We'll see how well the filesystem whitelist works.  I think it will
probably be good enough - at least for the foreseeable future.

Thanks for the feedback.

Sean