Bug 511236 - avc messages refer to wrong directory
avc messages refer to wrong directory
Product: Fedora
Classification: Fedora
Component: setroubleshoot (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: 517000
  Show dependency treegraph
Reported: 2009-07-14 07:48 EDT by Jón Fairbairn
Modified: 2010-12-05 01:43 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-12-05 01:43:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Redacted /proc/mounts (798 bytes, application/octet-stream)
2009-07-14 15:51 EDT, Jón Fairbairn
no flags Details
/usr/lib/python2.6/site-packages/setroubleshoot/audit_data.py (32.31 KB, application/octet-stream)
2009-07-15 11:00 EDT, Daniel Walsh
no flags Details
Backtrace from sealert (1.12 KB, application/octet-stream)
2009-07-15 11:51 EDT, Jón Fairbairn
no flags Details
sealert output (3.48 KB, text/plain)
2010-03-11 12:51 EST, Jón Fairbairn
no flags Details
Hack to compare rdev ids. (1.17 KB, patch)
2010-03-30 14:01 EDT, Jón Fairbairn
no flags Details | Diff
Better version of hack to compare rdev ids (1.00 KB, application/octet-stream)
2010-03-31 05:48 EDT, Jón Fairbairn
no flags Details

  None (edit)
Description Jón Fairbairn 2009-07-14 07:48:14 EDT
Description of problem:

As mentioned in bug #511209 I have two home partitions
mounted as /home and /home2. As a consequence of that bug,
/home2 had security type default_t, but I kept getting avcs
like this:

type=AVC msg=audit(1247566450.488:3375): avc:  denied  { search } for  pid=27572 comm="sshd" name="/" dev=dm-2 ino=2 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=dir

which refers to "/", when the problem really was with
/home2. Naturally I kept looking at the context of / and
finding it to be root_t and failing to discover the real problem.

Version-Release number of selected component (if applicable):
(Not sure which component is responsible for this.)

How reproducible:


Steps to Reproduce:

sudo mkdir /home3
dd if=/dev/zero of=/tmp/home3.img bs=1024 seek=$[20*1024] count=1
mke2fs -j /tmp/home3.img
sudo mount /tmp/home3.img /home3 -o loop

sudo useradd -d /home3/fred fred
sudo su fred
ssh localhost -o StrictHostKeyChecking=no

Actual results:
avc talking about "/"

Expected results:
avc talking about /home3

Additional info:

This doesn't happen if /home3 is simply a directory in /; in
that case the avc correctly identifies the problem directory
as /home3

I would have expected creating a user to modify the policy
so that the home directory is created with the right
context; this didn't happen for me when I tried the above
test. If it does, you would need to chcon -t default_t
/home3 to provoke the issue.
Comment 1 Daniel Walsh 2009-07-14 12:10:12 EDT
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
Comment 2 Jón Fairbairn 2009-07-14 12:27:45 EDT
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.
Comment 3 Daniel Walsh 2009-07-14 15:38:16 EDT
Can you attach your /proc/mounts.  I want to see if we can make setroubleshoot smart enough to translate the mountpoint backinto /home2
Comment 4 Jón Fairbairn 2009-07-14 15:51:41 EDT
Created attachment 351664 [details]
Redacted /proc/mounts

(Excluding stuff with ids and gids)
Comment 5 Daniel Walsh 2009-07-15 11:00:38 EDT
Created attachment 353836 [details]

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.
Comment 6 Jón Fairbairn 2009-07-15 11:51:09 EDT
Created attachment 353845 [details]
Backtrace from sealert
Comment 7 Jón Fairbairn 2009-07-15 11:52:03 EDT
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...
Comment 8 Daniel Walsh 2009-07-15 15:09:27 EDT
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.
Comment 9 Daniel Walsh 2009-08-21 17:53:39 EDT
Fixed in setroubleshoot in rawhide.
Comment 10 Jón Fairbairn 2010-03-11 12:47:46 EST
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/


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...)
Comment 11 Jón Fairbairn 2010-03-11 12:51:04 EST
Created attachment 399408 [details]
sealert output

For what it's worth, here's a dump from sealert of the message in question
Comment 12 Daniel Walsh 2010-03-29 15:30:42 EDT
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.
Comment 13 Daniel Walsh 2010-03-29 15:32:15 EDT
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.
Comment 14 Jón Fairbairn 2010-03-29 16:54:03 EDT
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="/"
Comment 15 Daniel Walsh 2010-03-30 08:57:08 EDT
dm-2 does not show up in your /proc/mounts at all then?  Does it show up in /proc/self/mountinfo?
Comment 16 Jón Fairbairn 2010-03-30 11:53:39 EDT
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
Comment 17 Daniel Walsh 2010-03-30 12:03:02 EDT
So no easy way to translate the path...

Eric any brilliant ideas?
Comment 18 Daniel Walsh 2010-03-30 12:05:04 EDT
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.
Comment 19 Jón Fairbairn 2010-03-30 12:23:49 EDT
/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
Comment 20 Jón Fairbairn 2010-03-30 12:40:46 EDT
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
Comment 21 Jón Fairbairn 2010-03-30 14:01:06 EDT
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...
Comment 22 Jón Fairbairn 2010-03-31 04:55:08 EDT
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.
Comment 23 Jón Fairbairn 2010-03-31 05:48:44 EDT
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.
Comment 25 Bug Zapper 2010-11-04 06:47:54 EDT
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: 
Comment 26 Bug Zapper 2010-12-05 01:43:17 EST
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.

Note You need to log in before you can comment on or make changes to this bug.