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!
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 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 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 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"/>
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 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!
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 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.
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 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?
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.
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
Ian Pilcher -
Stephen Smalley