Bug 511236

SELinux is not going to relabel automatically, that is up to the admin to correct.  

Have you tried to execute 

# semanage fcontext -a -e /home /home2
# restorecon -R -v /home2

I'm not complaining about the labelling in this bug; I'm complaining that the avc message refers to "/", rather than to /home2.  Once I knew which directory was mislabelled, I could easily correct it, but when the avc says "/", one tends to go "ls --lcon -d /", compare the root_t that that shows with the default_t in the avc and say "What the ****?"

ie current state is
$ matchpathcon /home2
/home2	system_u:object_r:home_root_t:s0

So that part is fine now, I hope, but if I try the test sequence included in this bug report, the avc (and an avc is not entirely unexpected) refers to "/", which is very unhelpful.


* * *

The comment about expecting creating a user with a nonstandard home directory to do the equivalent of "semanage fcontext -a -e /home /otherhome" was an aside and not part of this bug.

Can you attach your /proc/mounts.  I want to see if we can make setroubleshoot smart enough to translate the mountpoint backinto /home2

Created attachment 351664 [details]
Redacted /proc/mounts

(Excluding stuff with ids and gids)

Created attachment 353836 [details]
/usr/lib/python2.6/site-packages/setroubleshoot/audit_data.py

Could you replace your audit_data.py with this one, (Make sure you save your current one.

Then try sealert -a /var/log/audit/audit.log  on the /home2 avc and see if it figures out the correct name.

If this works I will update the setroubleshoot version in F11.

Created attachment 353845 [details]
Backtrace from sealert

That may be correct.  I'm not sure I understand the test correctly.

If I label /home2 to default_t, provoke the denial, extract the two resulting lines from /var/log/audit/audit.log into /tmp/audit.log and sealert -a /tmp/audit.log, the output correctly identifies dm-2 as /home2.

If instead I try to run sealert -a /var/log/audit/audit.log, I get a backtrace and sealert hangs. This doesn't happen with the rpm version of sealert.

I'll attach the backtrace...

Thanks, we are continuing to work on this problem.  The kernel gives us very little information so we are trying to figure out what the kernel is refering too in the AVC. 

In order for the kernel to give us complete information it takes about a 5% performance hit, not worth it.  So it is giving us the "/" since that is all the info it has.  It also gives us the device that it happens on.  We are trying to piece together the AVC with the /proc/mounts to see if we can figure out the mount point.  In your case /home1.  I will update with a new audit_data.py once we have one that works in multiple cases.

Fixed in setroubleshoot in rawhide.

This still seems have recurred with Fedora 12 selinux-policy-3.6.32-92.fc12.noarch Updating to that package (and associated selinux packages, or something else that updated at about that time) caused /home2 to be relabelled to etc_runtime_t

ls --lcon -ld /home2
drwxr-xr-x. 5 system_u:object_r:etc_runtime_t:s0 root root 4096 2009-07-14 09:20 /home2/

Strangely, 

matchpathcon /home2
/home2	system_u:object_r:home_root_t:s0

this was causing reports referring to "/" when they should have referred to /home2 (it took me a while to realise that this...)

Created attachment 399408 [details]
sealert output

For what it's worth, here's a dump from sealert of the message in question

I have checked this out on a couple of other packages and it seem like it is working.

The kernel gives setroubleshoot "/" for the root of the file system.

Setroubleshoot tries to guess the right path by opening /proc/mounts, it then looks at the second field begins with a "/".  If it does it does an lstat of the path and compares the inode.  If the inode matches it then checks to make sure the device is the same.

The code is in /usr/lib64/python2.6/site-packages/setroubleshoot/audit_data.py

If you know python take a look.  There could be a bug in there.

I don't know Python, but it's a bit like mangled Haskell, isn't it? :-)

The avc is:

node=calligramme.charmers type=AVC msg=audit(1268270194.32:1362): avc:  denied  { search } for  pid=9957 comm="sshd" name="/" dev=dm-2 ino=2 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_runtime_t:s0 tclass=dir

ie dev=dm-2 and ino=2

but the line in /proc/mounts is

/dev/mapper/CalligrammeMain-Home2 /home2 ext3 rw,seclabel,relatime,errors=continue,data=ordered 0 0

/dev/dm-2 and /dev/mapper/CalligrammeMain-Home2 are the same /device/ -- (253, 2)


but not textually equal (different inodes too) and I don't recognise any code to test for that (I admit to not understanding it fully; the line

     if i[0] == ("/dev/%s" % dev) or i[2] == dev:

seems to be comparing i[2] (the filesystem type, ext3 here) with the device, and I don't know what case that covers, though I don't think that's relevant here)

Anyhow, I think it gathers a list of mounts with inode=2 but fails to find /dev/dm-2 in it and leaves path="/"

dm-2 does not show up in your /proc/mounts at all then?  Does it show up in /proc/self/mountinfo?

No. It's referred to as /dev/mapper/CalligrammeMain-Home2 in both, though /proc/self/mountinfo does include the device number in the form 253:2

So no easy way to translate the path...

Eric any brilliant ideas?

Actually if I follow the symbolic links from /dev/mapper/CalligrammeMain-Home2 it will point me at the name.

I think the python needs to check if the name is a link and then follow the link.

/dev/mapper/CalligrammeMain-Home2 isn't a symlink, it's a block device.
Not even a link:

   $ stat /dev/mapper/CalligrammeMain-Home2 
     File: `/dev/mapper/CalligrammeMain-Home2'
     Size: 0         	Blocks: 0          IO Block: 4096   block special file
   Device: 5h/5d	Inode: 6976        Links: 1     Device type: fd,2
   [...]

   $ stat /dev/dm-2
     File: `/dev/dm-2'
     Size: 0         	Blocks: 0          IO Block: 4096   block special file
   Device: 5h/5d	Inode: 6960        Links: 1     Device type: fd,2
   [...]

Incidentally, lvm creates a symlink /dev/CalligrammeMain/Home2, and that points to /dev/mapper/CalligrammeMain-Home2 (rather than to /dev/dm-2). Which suggests to me that /dev/dm-2 is a kernel name that isn't used at higher levels.  Isn't there a mapping between the two names somewhere?

At any rate, you could check st_rdev:

   >>> os.lstat("/dev/mapper/CalligrammeMain-Home2").st_rdev == os.lstat("/dev/dm-2").st_rdev
   True

Created attachment 403537 [details]
Hack to compare rdev ids.

The attached patch finds the right mount point on my system when fed the avc in attachment#399408 [details]

Since I don't know python and don't understand most of the rest of sealert and I haven't tested it on any other data, I make no further claims about it...

Having thought about this further, isn't there something a bit odd about searching through inode numbers when path="/"? I don't have a definitive reference, but the root inode of almost all the filesystems I've looked at is either 1 or 2, so this is only going to halve the number of things to look at.

Created attachment 403688 [details]
Better version of hack to compare rdev ids

This one tests the rdev id earlier and uses stat rather than lstat so that symlinks in /dev are followed. I've left the inode comparison in as I don't know what cases that handes, but if dev_rdev == 0, (the device node isn't a device node?) the behaviour should be the same as before.

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.