SELinux denying chcon -- OUCH!

[Ian Pilcher]

A little background -- I have my music collection stored on 5 reiserfs
filesystems, on top of five separate software RAID devices (md4-md8).  I
use httpd to make them available on my *home* network (and if the RIAA
has a problem with that they can kiss my lilly-white...sorry).  I
generally mount them as /var/www/html/music/music{0,1,2,3,4}.

Today I rebooted my system (Fedora Core 5, fully updated) and got some
bizarre warnings about being unable to mount a block device read-only.
Sure enough...

audit(1143570731.388:11): avc:  denied  { mounton } for  pid=1703
comm="mount" name="music0" dev=md1 ino=131232
scontext=system_u:system_r:mount_t:s0
tcontext=root:object_r:httpd_sys_content_t:s0 tclass=dir

Hmm, looks like a special context is now needed for mount points.  I can
see why that might be a good idea, so...

chcon system_u:system_r:mount_t /var/www/html/music/*

chcon: failed to change context of /var/www/html/music/music0 to
system_u:system_r:mount_t: Permission denied

type=AVC msg=audit(1143571740.714:59): avc:  denied  { relabelto } for
pid=3036 comm="chcon" name="music0" dev=md1 ino=131232
scontext=user_u:system_r:unconfined_t:s0-s0:c0.c255
tcontext=system_u:system_r:mount_t:s0 tclass=dir

This is either a learning opportunity for me, or a serious problem.  I
can't wait to find out which.

Thanks!

-- 
========================================================================
Ian Pilcher                                        i.pilcher(a)comcast.net
========================================================================

[Stephen Smalley]

On Tue, 2006-03-28 at 12:51 -0600, Ian Pilcher wrote:
>  A little background -- I have my music collection stored on 5
> reiserfs
>  filesystems, on top of five separate software RAID devices (md4-md8).  I
>  use httpd to make them available on my *home* network (and if the RIAA
>  has a problem with that they can kiss my lilly-white...sorry).  I
>  generally mount them as /var/www/html/music/music{0,1,2,3,4}.
>  
>  Today I rebooted my system (Fedora Core 5, fully updated) and got some
>  bizarre warnings about being unable to mount a block device read-only.
>  Sure enough...
>  
>  audit(1143570731.388:11): avc:  denied  { mounton } for  pid=1703
>  comm="mount" name="music0" dev=md1 ino=131232
>  scontext=system_u:system_r:mount_t:s0
>  tcontext=root:object_r:httpd_sys_content_t:s0 tclass=dir
>  
>  Hmm, looks like a special context is now needed for mount points.  I can
>  see why that might be a good idea, so...
>  
>  chcon system_u:system_r:mount_t /var/www/html/music/*
>  
>  chcon: failed to change context of /var/www/html/music/music0 to
>  system_u:system_r:mount_t: Permission denied
>  
>  type=AVC msg=audit(1143571740.714:59): avc:  denied  { relabelto } for
>  pid=3036 comm="chcon" name="music0" dev=md1 ino=131232
>  scontext=user_u:system_r:unconfined_t:s0-s0:c0.c255
>  tcontext=system_u:system_r:mount_t:s0 tclass=dir
>  
>  This is either a learning opportunity for me, or a serious problem.  I
>  can't wait to find out which. 
mount_t is a domain - a type for a process running the mount program.
Not a file type to assign to mount point directories.  Not sure what
type to recommend for what you describe - Dan?  Likely need a generic
mnt_t or similar with the mountpoint attribute?

-- 
Stephen Smalley
National Security Agency

[Ian Pilcher]

Stephen Smalley wrote:
>  
>  mount_t is a domain - a type for a process running the mount program.
>  Not a file type to assign to mount point directories.  Not sure what
>  type to recommend for what you describe - Dan?  Likely need a generic
>  mnt_t or similar with the mountpoint attribute?
>   
I have changed the type of the mount points to mnt_t.  It doesn't look
like this will cause a problem for httpd, because once the filesystem is
mounted, the type of its root directory appears to "mask" the type of
the mount point.

I should have mentioned before that I have no problem mounting these
filesystems as a logged in root user (mount -a); the problem only occurs
when booting the system.

After changing the type of the mount points and rebooting, I am now
getting this:

audit(1143579721.063:15): avc:  denied  { search } for  pid=1709
comm="mount" name="/" dev=md8 ino=2
scontext=system_u:system_r:mount_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir

It looks like the mount command is looking for something in the root
directory of the filesystem, but I have no idea what that might be.

Thanks!

-- 
========================================================================
Ian Pilcher                                        i.pilcher(a)comcast.net
========================================================================

ReiserFS chicken and egg

[Ian Pilcher]

Ian Pilcher wrote:
>  audit(1143579721.063:15): avc:  denied  { search } for  pid=1709
>  comm="mount" name="/" dev=md8 ino=2
>  scontext=system_u:system_r:mount_t:s0
>  tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir 
I created a brand new ReiserFS filesystem on a spare device and tried to
mount it on /mnt/tmp via /etc/fstab.  Upon rebooting, dmesg contains:

ReiserFS: md9: warning: xattrs/ACLs enabled and couldn't find/create
.reiserfs_priv.  Failing mount.

So it looks like the mount command can't find the SELinux contexts for
the filesystem, because the SELinux contexts for the filesystem aren't
set, because it can't find the SELinux contexts for the filesystem....

-- 
========================================================================
Ian Pilcher                                        i.pilcher(a)comcast.net
========================================================================

ReiserFS chicken and egg

[Ian Pilcher]

Ian Pilcher wrote:
>  
>  So it looks like the mount command can't find the SELinux contexts for
>  the filesystem, because the SELinux contexts for the filesystem aren't
>  set, because it can't find the SELinux contexts for the filesystem....
>   
I have the most fascinating conversations with myself...

The following indicates that ReiserFS is simply broken with SELinux:

https://www.redhat.com/archives/fedora-test-list/2006-January/msg00833.html

<sigh type="heavy"/>

-- 
========================================================================
Ian Pilcher                                        i.pilcher(a)comcast.net
========================================================================

ReiserFS chicken and egg

[Stephen Smalley]

On Tue, 2006-03-28 at 15:52 -0600, Ian Pilcher wrote:
>  Ian Pilcher wrote:
>  > audit(1143579721.063:15): avc:  denied  { search } for  pid=1709
>  > comm="mount" name="/" dev=md8 ino=2
>  > scontext=system_u:system_r:mount_t:s0
>  > tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir
>  
>  I created a brand new ReiserFS filesystem on a spare device and tried to
>  mount it on /mnt/tmp via /etc/fstab.  Upon rebooting, dmesg contains:
>  
>  ReiserFS: md9: warning: xattrs/ACLs enabled and couldn't find/create
>  .reiserfs_priv.  Failing mount.
>  
>  So it looks like the mount command can't find the SELinux contexts for
>  the filesystem, because the SELinux contexts for the filesystem aren't
>  set, because it can't find the SELinux contexts for the filesystem.... 
Sorry, reiserfs xattrs are known to be broken with SELinux at present,
because reiserfs doesn't yet implement the inode_init_security method
for labeling new inodes atomically at creation time.  As a workaround,
mount it with a context= mount to override the use of xattrs.

Dan and Chris - please drop the fs_use_xattr line for reiserfs in policy
and possibly add a genfscon entry back for reiserfs so that SELinux
doesn't try using xattrs on reiserfs.

-- 
Stephen Smalley
National Security Agency

ReiserFS chicken and egg

[Ian Pilcher]

Stephen Smalley wrote:
>  Sorry, reiserfs xattrs are known to be broken with SELinux at
> present,
>  because reiserfs doesn't yet implement the inode_init_security method
>  for labeling new inodes atomically at creation time.  As a workaround,
>  mount it with a context= mount to override the use of xattrs. 
I tried context=system_u:object_r:file_t:s0 and got the same error.  Is
there something else I should be using?

Thanks!

-- 
========================================================================
Ian Pilcher                                        i.pilcher(a)comcast.net
========================================================================

ReiserFS chicken and egg

[Stephen Smalley]

On Wed, 2006-03-29 at 06:27 -0600, Ian Pilcher wrote:
>  Stephen Smalley wrote:
>  > Sorry, reiserfs xattrs are known to be broken with SELinux at present,
>  > because reiserfs doesn't yet implement the inode_init_security method
>  > for labeling new inodes atomically at creation time.  As a workaround,
>  > mount it with a context= mount to override the use of xattrs.
>  
>  I tried context=system_u:object_r:file_t:s0 and got the same error.  Is
>  there something else I should be using? 
By the "same error", you mean another avc denial for search access to
unlabeled_t:dir by mount_t?  Did you get a SELinux:  initialized (dev
xxx, type reiserfs), uses mountpoint labeling message
in /var/log/messages?

-- 
Stephen Smalley
National Security Agency

ReiserFS chicken and egg

[Ian Pilcher]

Stephen Smalley wrote:
>  On Wed, 2006-03-29 at 06:27 -0600, Ian Pilcher wrote:
> > Stephen Smalley wrote:
> >> Sorry, reiserfs xattrs are known to be broken with SELinux at present,
> >> because reiserfs doesn't yet implement the inode_init_security method
> >> for labeling new inodes atomically at creation time.  As a workaround,
> >> mount it with a context= mount to override the use of xattrs.
> > I tried context=system_u:object_r:file_t:s0 and got the same error.  Is
> > there something else I should be using?
>  
>  By the "same error", you mean another avc denial for search access to
>  unlabeled_t:dir by mount_t?  Did you get a SELinux:  initialized (dev
>  xxx, type reiserfs), uses mountpoint labeling message
>  in /var/log/messages?
>   
Sorry about the delay...jury duty.

Just tried again to be sure:

  mkfs.reiserfs /dev/md9

/etc/fstab contains:

  /dev/md9 /mnt/tmp reiserfs context=system_u:object_r:file_t:s0 0 2

Rebooted and the mount failed.  dmesg | grep md9 shows:

audit(1143660461.416:15): avc:  denied  { search } for  pid=1714
comm="mount" name="/" dev=md9 ino=2
scontext=system_u:system_r:mount_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir
ReiserFS: md9: warning: xattrs/ACLs enabled and couldn't find/create
.reiserfs_priv. Failing mount.

It doesn't look like the context option had any affect at all.

-- 
========================================================================
Ian Pilcher                                        i.pilcher(a)comcast.net
========================================================================

ReiserFS chicken and egg

[Stephen Smalley]

On Wed, 2006-03-29 at 13:34 -0600, Ian Pilcher wrote:
>  Sorry about the delay...jury duty.
>  
>  Just tried again to be sure:
>  
>    mkfs.reiserfs /dev/md9
>  
>  /etc/fstab contains:
>  
>    /dev/md9 /mnt/tmp reiserfs context=system_u:object_r:file_t:s0 0 2
>  
>  Rebooted and the mount failed.  dmesg | grep md9 shows:
>  
>  audit(1143660461.416:15): avc:  denied  { search } for  pid=1714
>  comm="mount" name="/" dev=md9 ino=2
>  scontext=system_u:system_r:mount_t:s0
>  tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir
>  ReiserFS: md9: warning: xattrs/ACLs enabled and couldn't find/create
>  .reiserfs_priv. Failing mount.
>  
>  It doesn't look like the context option had any affect at all. 
I think we are encountering the denial before we reach the processing of
the context option.  The setup of the superblock security data and the
root directory security data happens upon security_sb_kern_mount, but
this is called after the filesystem returns from its get_sb method.
Unfortunately, reiserfs apparently tries to access the xattr directory
during get_sb, so there is an attempted lookup before SELinux has
initialized the security state on the root directory, and we get a
denial on unlabeled_t.  I guess you need to allow mount_t
unlabeled_t:dir search; to workaround it.

-- 
Stephen Smalley
National Security Agency

ReiserFS chicken and egg

[Daniel J Walsh]

Stephen Smalley wrote:
>  On Wed, 2006-03-29 at 13:34 -0600, Ian Pilcher wrote:
>    
> > Sorry about the delay...jury duty.
> >
> > Just tried again to be sure:
> >
> >   mkfs.reiserfs /dev/md9
> >
> > /etc/fstab contains:
> >
> >   /dev/md9 /mnt/tmp reiserfs context=system_u:object_r:file_t:s0 0 2
> >
> > Rebooted and the mount failed.  dmesg | grep md9 shows:
> >
> > audit(1143660461.416:15): avc:  denied  { search } for  pid=1714
> > comm="mount" name="/" dev=md9 ino=2
> > scontext=system_u:system_r:mount_t:s0
> > tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir
> > ReiserFS: md9: warning: xattrs/ACLs enabled and couldn't find/create
> > .reiserfs_priv. Failing mount.
> >
> > It doesn't look like the context option had any affect at all.
> >     
>
>  I think we are encountering the denial before we reach the processing of
>  the context option.  The setup of the superblock security data and the
>  root directory security data happens upon security_sb_kern_mount, but
>  this is called after the filesystem returns from its get_sb method.
>  Unfortunately, reiserfs apparently tries to access the xattr directory
>  during get_sb, so there is an attempted lookup before SELinux has
>  initialized the security state on the root directory, and we get a
>  denial on unlabeled_t.  I guess you need to allow mount_t
>  unlabeled_t:dir search; to workaround it.
>
>     
Should we allow this in policy?

ReiserFS chicken and egg

[Stephen Smalley]

On Thu, 2006-03-30 at 15:32 -0500, Daniel J Walsh wrote:
>  Stephen Smalley wrote:
>  > On Wed, 2006-03-29 at 13:34 -0600, Ian Pilcher wrote:
>  >   
>  >> Sorry about the delay...jury duty.
>  >>
>  >> Just tried again to be sure:
>  >>
>  >>   mkfs.reiserfs /dev/md9
>  >>
>  >> /etc/fstab contains:
>  >>
>  >>   /dev/md9 /mnt/tmp reiserfs context=system_u:object_r:file_t:s0 0 2
>  >>
>  >> Rebooted and the mount failed.  dmesg | grep md9 shows:
>  >>
>  >> audit(1143660461.416:15): avc:  denied  { search } for  pid=1714
>  >> comm="mount" name="/" dev=md9 ino=2
>  >> scontext=system_u:system_r:mount_t:s0
>  >> tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir
>  >> ReiserFS: md9: warning: xattrs/ACLs enabled and couldn't find/create
>  >> .reiserfs_priv. Failing mount.
>  >>
>  >> It doesn't look like the context option had any affect at all.
>  >>     
>  >
>  > I think we are encountering the denial before we reach the processing of
>  > the context option.  The setup of the superblock security data and the
>  > root directory security data happens upon security_sb_kern_mount, but
>  > this is called after the filesystem returns from its get_sb method.
>  > Unfortunately, reiserfs apparently tries to access the xattr directory
>  > during get_sb, so there is an attempted lookup before SELinux has
>  > initialized the security state on the root directory, and we get a
>  > denial on unlabeled_t.  I guess you need to allow mount_t
>  > unlabeled_t:dir search; to workaround it.
>  >
>  >   
>  Should we allow this in policy? 
Unclear - it can easily be added by a module on the end systems, and it
is a definite corner case that is not usually required.

-- 
Stephen Smalley
National Security Agency