Re: Mount & SELinux problems, session saving in GNOME

[Stephen Smalley]

On Sun, 2006-04-16 at 22:47 +0300, Lauri wrote:
>  Hi!
>  
>  With SELinux enabled, the system won't mount ReiserFS partitions,
>  SELinux will deny it:
>  
>     Apr 15 14:19:38 localhost kernel: ReiserFS: hdb1: found reiserfs 
>  format "3.6" with standard journal
>     Apr 15 14:19:38 localhost kernel: ReiserFS: hdb1: using ordered data mode
>     Apr 15 14:19:38 localhost kernel: ReiserFS: hdb1: journal params: 
>  device hdb1, size 8192, journal first block 18, max trans len 1024, max 
>  batch 900, max commit age 30, max trans age 30
>     Apr 15 14:19:38 localhost kernel: ReiserFS: hdb1: checking 
>  transaction log (hdb1)
>     Apr 15 14:19:38 localhost kernel: ReiserFS: hdb1: Using r5 hash to 
>  sort names
>     Apr 15 14:19:38 localhost kernel: audit(1145099700.155:2): avc: 
>  denied  { search } for  pid=1278 comm="mount" name="/" dev=hdb1 ino=2
>
>  scontext=system_u:system_r:mount_t:s0 
>  tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir
>     Apr 15 14:19:38 localhost kernel: ReiserFS: hdb1: warning: 
>  xattrs/ACLs enabled and couldn't find/create .reiserfs_priv. Failing mount.
>  
>  and mount will output:
>  
>     mount: Operation not supported 
Added fedora-selinux-list to the cc line.
SELinux and the reiserfs xattr implementation (xattrs stored as regular
files) don't get along presently.  There are a couple of problems, one
related to mount-time initialization (as above) since reiserfs ends up
trying to search the root directory for the xattr root before SELinux
has a chance to set up its security label incore, and one related to
atomic labeling of new inodes.  If you are using reiserfs for your
primary filesystems (e.g. /, /usr, ...), then you likely just have to
disable SELinux.  If you are only using it for e.g. /home or other kinds
of data repositories that can be handled at a single security label
(with some loss in granularity of control), you may be able to get by
via a local policy module and a context mount, details below. 

You can workaround the above specific denial by creating a policy
module, ala:
$ mkdir reiser
$ cd reiser
$ vi reiser.te
i(nsert)
# Declare the policy module, with a name and version.
policy_module(reiser, 1.0)

# Tell the module infrastructure what we need from the base policy 
# or other previously inserted modules.
require {
	# Need these two types to already be defined.
	type mount_t;
	type unlabeled_t;
};

# Define the content of the actual policy module.
# In this case, just a single allow rule.
allow mount_t unlabeled_t:dir search;
:wq
$ make -f /usr/share/selinux/devel/Makefile
$ su 
# /usr/sbin/semodule -i reiser.pp

This will add the permission required to search the root directory for
the xattr subtree.   (audit2allow also can be used to generate such
modules, via the -M option).

Then, you likely want to do a context mount to force all files in the
reiserfs filesystem to a single label, because reiserfs doesn't support
proper labeling of new inodes yet.  Ala:
# mount -o context=system_u:object_r:default_t:s0 <dirname>

But replacing default_t with some type appropriate to the data stored
there.  If that works, then you'll want to add the context= option to
your fstab file for future mounting.

>  SELinux also denys loading of some *.so files, for example a script
> of
>  XChat, I used following code to correct it:
>  
>     chcon -t texrel_shlib_t /usr/lib/xhat/*.so
>  
>  But this gets reset after reboot. 
It shouldn't be reset upon reboot unless a relabel occurred.
Is /usr/lib on a reiserfs filesystem?  If so, that is the problem.
If not, then you can make the above change permanent across
relabels/policy updates via semanage, e.g.
# /usr/sbin/semanage fcontext -a -t textrel_shlib_t '/usr/lib/xhat/.*\.so(\.[^/]*)*

Then a /sbin/restorecon -Rv /usr/lib/xhat shouldn't disturb those
settings.

>  During shutdown, umount will fail if the name of the CD contains a
>  whitespace. Something like this is used (from /etc/mtab):
>  
>     /media/Led\040Zeppelin
>  
>  
>  When logging out, saving a session isn't offered as it was in FC4, so,
>  in order to save the session, I have to switch on automatic saving, log
>  out and then switch it off again.
>  
>  
>  Running on FC5, kernel 2.6.16-1.2080_FC5 or
>  2.6.16-1.2080_2.rhfc5.cubbi_suspend2 (does it make any difference?). 
-- 
Stephen Smalley
National Security Agency

Mount & SELinux problems, session saving in GNOME

[Lauri]

>  On Sun, 2006-04-16 at 22:47 +0300, Lauri wrote:
> > Hi!
> >
> > With SELinux enabled, the system won't mount ReiserFS partitions,
> > SELinux will deny it:
> >
> >    Apr 15 14:19:38 localhost kernel: ReiserFS: hdb1: found reiserfs 
> > format "3.6" with standard journal
> >    Apr 15 14:19:38 localhost kernel: ReiserFS: hdb1: using ordered data mode
> >    Apr 15 14:19:38 localhost kernel: ReiserFS: hdb1: journal params: 
> > device hdb1, size 8192, journal first block 18, max trans len 1024, max 
> > batch 900, max commit age 30, max trans age 30
> >    Apr 15 14:19:38 localhost kernel: ReiserFS: hdb1: checking 
> > transaction log (hdb1)
> >    Apr 15 14:19:38 localhost kernel: ReiserFS: hdb1: Using r5 hash to 
> > sort names
> >    Apr 15 14:19:38 localhost kernel: audit(1145099700.155:2): avc: 
> > denied  { search } for  pid=1278 comm="mount" name="/" dev=hdb1
> ino=2 
> > scontext=system_u:system_r:mount_t:s0 
> > tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir
> >    Apr 15 14:19:38 localhost kernel: ReiserFS: hdb1: warning: 
> > xattrs/ACLs enabled and couldn't find/create .reiserfs_priv. Failing mount.
> >
> > and mount will output:
> >
> >    mount: Operation not supported
>  
>  Added fedora-selinux-list to the cc line.
>  SELinux and the reiserfs xattr implementation (xattrs stored as regular
>  files) don't get along presently.  There are a couple of problems, one
>  related to mount-time initialization (as above) since reiserfs ends up
>  trying to search the root directory for the xattr root before SELinux
>  has a chance to set up its security label incore, and one related to
>  atomic labeling of new inodes.  If you are using reiserfs for your
>  primary filesystems (e.g. /, /usr, ...), then you likely just have to
>  disable SELinux.  If you are only using it for e.g. /home or other kinds
>  of data repositories that can be handled at a single security label
>  (with some loss in granularity of control), you may be able to get by
>  via a local policy module and a context mount, details below. 
>  
>  You can workaround the above specific denial by creating a policy
>  module, ala:
>  $ mkdir reiser
>  $ cd reiser
>  $ vi reiser.te
>  i(nsert)
>  # Declare the policy module, with a name and version.
>  policy_module(reiser, 1.0)
>  
>  # Tell the module infrastructure what we need from the base policy 
>  # or other previously inserted modules.
>  require {
>  	# Need these two types to already be defined.
>  	type mount_t;
>  	type unlabeled_t;
>  };
>  
>  # Define the content of the actual policy module.
>  # In this case, just a single allow rule.
>  allow mount_t unlabeled_t:dir search;
>  :wq
>  $ make -f /usr/share/selinux/devel/Makefile
>  $ su 
>  # /usr/sbin/semodule -i reiser.pp
>  
>  This will add the permission required to search the root directory for
>  the xattr subtree.   (audit2allow also can be used to generate such
>  modules, via the -M option).
>  
>  Then, you likely want to do a context mount to force all files in the
>  reiserfs filesystem to a single label, because reiserfs doesn't support
>  proper labeling of new inodes yet.  Ala:
>  # mount -o context=system_u:object_r:default_t:s0 <dirname>
>  
>  But replacing default_t with some type appropriate to the data stored
>  there.  If that works, then you'll want to add the context= option to
>  your fstab file for future mounting. 
To try that I enabled SELinux again. It relabelled the system and now
gives new error:

   Apr 17 18:33:08 localhost kernel: [drm] Loading R200 Microcode
   Apr 17 18:33:10 localhost kernel: audit(1145287990.371:10): avc: 
denied  { execmod } for  pid=3964 comm="metacity" name="libGL.so.1.2"

dev=hda5 ino=1235892 scontext=user_u:system_r:unconfined_t:s0 
tcontext=system_u:object_r:lib_t:s0 tclass=file

As I understand, it tries to load some files from /usr/lib/ati-fglrx.
GNOME fails to start.

I'm using ext3 for / and reiserfs for some additional partitions
(/data1, /data2).

Lauri


>  
> > SELinux also denys loading of some *.so files, for example a script of
> > XChat, I used following code to correct it:
> >
> >    chcon -t texrel_shlib_t /usr/lib/xhat/*.so
> >
> > But this gets reset after reboot.
>  
>  It shouldn't be reset upon reboot unless a relabel occurred.
>  Is /usr/lib on a reiserfs filesystem?  If so, that is the problem.
>  If not, then you can make the above change permanent across
>  relabels/policy updates via semanage, e.g.
>  # /usr/sbin/semanage fcontext -a -t textrel_shlib_t '/usr/lib/xhat/.*\.so(\.[^/]*)*
>  
>  Then a /sbin/restorecon -Rv /usr/lib/xhat shouldn't disturb those
>  settings.
>  
> > During shutdown, umount will fail if the name of the CD contains a
> > whitespace. Something like this is used (from /etc/mtab):
> >
> >    /media/Led\040Zeppelin
> >
> >
> > When logging out, saving a session isn't offered as it was in FC4, so,
> > in order to save the session, I have to switch on automatic saving, log
> > out and then switch it off again.
> >
> >
> > Running on FC5, kernel 2.6.16-1.2080_FC5 or
> > 2.6.16-1.2080_2.rhfc5.cubbi_suspend2 (does it make any difference?).
>

Mount & SELinux problems, session saving in GNOME

[Stephen Smalley]

On Mon, 2006-04-17 at 18:58 +0300, Lauri wrote:
>  To try that I enabled SELinux again. It relabelled the system and
> now
>  gives new error:
>  
>     Apr 17 18:33:08 localhost kernel: [drm] Loading R200 Microcode
>     Apr 17 18:33:10 localhost kernel: audit(1145287990.371:10): avc: 
>  denied  { execmod } for  pid=3964 comm="metacity" name="libGL.so.1.2"
>
>  dev=hda5 ino=1235892 scontext=user_u:system_r:unconfined_t:s0 
>  tcontext=system_u:object_r:lib_t:s0 tclass=file 
Hmmm...and /usr/lib is on your ext3 filesystem?
# /sbin/restorecon -v /usr/lib/libGL.so.1.2

That should be textrel_shlib_t.  Looks ok on an up-to-date FC5 system
here.

>  As I understand, it tries to load some files from
> /usr/lib/ati-fglrx.
>  GNOME fails to start.
>  
>  I'm using ext3 for / and reiserfs for some additional partitions
>  (/data1, /data2). 
In that case, the local policy module + context mount option should
enable you to access the reiserfs partitions sufficiently.

-- 
Stephen Smalley
National Security Agency

Mount & SELinux problems, session saving in GNOME

[Lauri]

>  On Mon, 2006-04-17 at 18:58 +0300, Lauri wrote:
> > To try that I enabled SELinux again. It relabelled the system and now
> > gives new error:
> >
> >    Apr 17 18:33:08 localhost kernel: [drm] Loading R200 Microcode
> >    Apr 17 18:33:10 localhost kernel: audit(1145287990.371:10): avc: 
> > denied  { execmod } for  pid=3964 comm="metacity"
> name="libGL.so.1.2" 
> > dev=hda5 ino=1235892 scontext=user_u:system_r:unconfined_t:s0 
> > tcontext=system_u:object_r:lib_t:s0 tclass=file
>  
>  Hmmm...and /usr/lib is on your ext3 filesystem?
>  # /sbin/restorecon -v /usr/lib/libGL.so.1.2
>  
>  That should be textrel_shlib_t.  Looks ok on an up-to-date FC5 system
>  here.
>   
I tried that, but it didn't work. I'll just disable SELinux then and try
again some other time. :) As a home user, I don't really think I need
it... Or do I?

Lauri


> > As I understand, it tries to load some files from
> /usr/lib/ati-fglrx.
> > GNOME fails to start.
> >
> > I'm using ext3 for / and reiserfs for some additional partitions
> > (/data1, /data2).
>  
>  In that case, the local policy module + context mount option should
>  enable you to access the reiserfs partitions sufficiently.
>

Mount & SELinux problems, session saving in GNOME

[Stephen Smalley]

On Mon, 2006-04-17 at 19:58 +0300, Lauri wrote:
>  > On Mon, 2006-04-17 at 18:58 +0300, Lauri wrote:
>  >> To try that I enabled SELinux again. It relabelled the system and now
>  >> gives new error:
>  >>
>  >>    Apr 17 18:33:08 localhost kernel: [drm] Loading R200 Microcode
>  >>    Apr 17 18:33:10 localhost kernel: audit(1145287990.371:10): avc: 
>  >> denied  { execmod } for  pid=3964 comm="metacity"
> name="libGL.so.1.2" 
>  >> dev=hda5 ino=1235892 scontext=user_u:system_r:unconfined_t:s0 
>  >> tcontext=system_u:object_r:lib_t:s0 tclass=file
>  > 
>  > Hmmm...and /usr/lib is on your ext3 filesystem?
>  > # /sbin/restorecon -v /usr/lib/libGL.so.1.2
>  > 
>  > That should be textrel_shlib_t.  Looks ok on an up-to-date FC5 system
>  > here.
>  > 
>  
>  I tried that, but it didn't work. I'll just disable SELinux then and try
>  again some other time. :) As a home user, I don't really think I need
>  it... Or do I? 
If you don't mind, bugzilla the issue first with as much detail as
possible, so that someone can at least try to investigate it further.
Whether or not you "need" it is a matter of (often fiery) debate, and
naturally your call to make.  Motivation for having a mandatory access
control (MAC) mechanism in the OS is discussed in the paper available
from the link below.
http://www.nsa.gov/selinux/papers/inevit-abs.cfm

It isn't a panacea or silver bullet for security, but it is a basic
building block necessary for building higher level security guarantees
and countering the threat posed by flawed and malicious applications.
Whether or not SELinux will help you with your specific needs at this
time is another question; it depends on your situation.

The other potential motivation for enabling it and working through
issues is to help the community with improving it for the long term
overall benefit of everyone, but you have to weigh the cost/benefit
tradeoffs there, naturally.  Reporting the bug is at least a step in
contributing there.

-- 
Stephen Smalley
National Security Agency

Mount & SELinux problems, session saving in GNOME

On Mon, 17 Apr 2006 19:58:28 +0300, Lauri said:
>  > On Mon, 2006-04-17 at 18:58 +0300, Lauri wrote:
>  >> To try that I enabled SELinux again. It relabelled the system and now
>  >> gives new error:
>  >>
>  >>    Apr 17 18:33:08 localhost kernel: [drm] Loading R200 Microcode
>  >>    Apr 17 18:33:10 localhost kernel: audit(1145287990.371:10): avc: 
>  >> denied  { execmod } for  pid=3964 comm="metacity"
> name="libGL.so.1.2" 
>  >> dev=hda5 ino=1235892 scontext=user_u:system_r:unconfined_t:s0 
>  >> tcontext=system_u:object_r:lib_t:s0 tclass=file
>  > 
>  > Hmmm...and /usr/lib is on your ext3 filesystem?
>  > # /sbin/restorecon -v /usr/lib/libGL.so.1.2
>  > 
>  > That should be textrel_shlib_t.  Looks ok on an up-to-date FC5 system
>  > here.
>  > 
>  
>  I tried that, but it didn't work. I'll just disable SELinux then and try
>  again some other time. :) As a home user, I don't really think I need
>  it... Or do I? 
This has the distinct aroma of an NVidia binary driver - installing that
will replace your libGL.so, and I'm not very confident at the installer's
ability to set textrel_shlib_t when needed, given that the flipping thing needs
to be run with enforcing=0 to even *work*.