Bug 447048

Created attachment 308553 [details]
SELinux alert report for version 3.3.1-62.fc9

Issue still occurs for selinux-policy-3.3.1-62.fc9.

Does this happen when you execute service mrtg start while sitting in /root or
does it happen on boot?

You can allow this for now.

# audit2allow -M mypol -l -i /var/log/audit/audit.log
# semodule -i mypol.pp

Fixed in selinux-policy-3.3.1-71.fc9.noarch

I just upgraded to selinux-policy-3.3.1-84.fc9 from selinux-policy-3.3.1-64.fc9.  Before I did I got two complaints about mrtg being denied to "search" in root (user_home_dir_t) every time cron ran mrtg.  After the upgrade I get two complaints each time instead, now about mrtg not being allowed to "read" the same directory.  See the details below.  (Inode 5341185 is /root.)

I doubt mrtg really needs access to /root, but it is started for the root user.  That means it will have /root as its current directory when starting, which is the cause for those problems, I guess.

time->Tue Aug 26 11:50:01 2008
type=SYSCALL msg=audit(1219744201.531:59723): arch=c000003e syscall=2 success=no exit=-13 a0=201058b a1=0 a2=4000 a3=7fff1c463ee0 items=0 ppid=4457 pid=4460 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=84 comm="mrtg" exe="/usr/bin/perl" subj=system_u:system_r:mrtg_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1219744201.531:59723): avc:  denied  { read } for  pid=4460 comm="mrtg" name="root" dev=dm-0 ino=5341185 scontext=system_u:system_r:mrtg_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_dir_t:s0 tclass=dir
----
time->Tue Aug 26 11:50:01 2008
type=SYSCALL msg=audit(1219744201.531:59724): arch=c000003e syscall=2 success=no exit=-13 a0=201058b a1=0 a2=4000 a3=0 items=0 ppid=4457 pid=4460 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=84 comm="mrtg" exe="/usr/bin/perl" subj=system_u:system_r:mrtg_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1219744201.531:59724): avc:  denied  { read } for  pid=4460 comm="mrtg" name="root" dev=dm-0 ino=5341185 scontext=system_u:system_r:mrtg_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_dir_t:s0 tclass=dir

# restorecon -R -v /root

Does this fix the problem?

No, I've already tried that.  (Is there anything in the policy that would allow mrtg_t to "search" user_home_dir_t?  I couldn't find anything, but I tend often get lost among all those macros, so I may be wrong.)

What does 

matchpathcon /root 

Say?

22:16 freddi$ sudo matchpathcon /root
/root   system_u:object_r:user_home_dir_t

Well then there is definitely something wrong with this machines policy

# rpm -q selinux-policy
selinux-policy-3.3.1-85.fc9.noarch

# matchpathcon /root
/root	system_u:object_r:admin_home_t:s0


/root was labeled user_home_dir_t back in Fedora 8 I believe but something is wrong.

grep /root /etc/selinux/targeted/contexts/files/* 
/etc/selinux/targeted/contexts/files/file_contexts:/root(/.*)?	system_u:object_r:admin_home_t:s0
/etc/selinux/targeted/contexts/files/file_contexts:/usr/lib(64)?/courier/rootcerts(/.*)?	system_u:object_r:courier_etc_t:s0
/etc/selinux/targeted/contexts/files/file_contexts:/dev/root	-b	system_u:object_r:fixed_disk_device_t:s0
/etc/selinux/targeted/contexts/files/file_contexts:/root/restore	-d	system_u:object_r:amanda_recover_dir_t:s0
/etc/selinux/targeted/contexts/files/file_contexts:/root/\.default_contexts	--	system_u:object_r:default_context_t:s0

I get the same matches as you show in file_contexts.  But I also get loads of matches in file_contexts.homedirs, including

/etc/selinux/targeted/contexts/files/file_contexts.homedirs:/root       -d     system_u:object_r:user_home_dir_t:s0
/etc/selinux/targeted/contexts/files/file_contexts.homedirs:/root       -l     system_u:object_r:user_home_dir_t:s0

(The has been upgraded, not reinstalled, since earlier releases if that matters.)

If you run genhomedircon is the bad context still there?

Do you have some funny entry for /root in your /etc/passwd?

IE Do you have a service which a homedir of /root with a uid > 500 and a shell other then /bin/true or /sbin/nologin?

> If you run genhomedircon is the bad context still there?

Yes.

> Do you have some funny entry for /root in your /etc/passwd?

Nothing that strikes me as funny:

mimmi> grep /root /etc/passwd
root:x:0:0:root:/root:/bin/bash
operator:x:11:0:operator:/root:/sbin/nologin

And you are not using some kind of network password database?

ldap or nis?

# getent passwd | grep /root
root:x:0:0:root:/root:/bin/bash
operator:x:11:0:operator:/root:/sbin/nologin

This machine has only local data.

mimmi> getent passwd|grep /root
root:x:0:0:root:/root:/bin/bash
operator:x:11:0:operator:/root:/sbin/nologin
mimmi> grep passwd /etc/nsswitch.conf 
#passwd:    db files nisplus nis
passwd:     files

I take it that genhomedircon should not generate patterns for accounts with "uid < 500 or a shell other then /bin/true or /sbin/nologin".  What package implements that rule?  Is it done directly in policycoreutils, or some of its dependencies?  (I want to check I don't have any local modifications that breaks things.)

Yes but this has got me baffled.  I will take a look at the code.

What does 
# semanage login -l 
and
# semanage user -l

output?

rpm -q policycoreutils libsemanage

mimmi> sudo semanage login -l

Inloggningsnamn           SELinux-användare        MLS/MCS-intervall        

__default__               unconfined_u              SystemLow-SystemHigh     
root                      root                      s0-s0:c0.c255            
system_u                  system_u                  SystemLow-SystemHigh     

mimmi> sudo semanage user -l

                Märkning  MLS/       MLS/                          
SELinux-användare Prefix     MCS-nivå  MCS-intervall                  SELinux-roller

root            user       s0         SystemLow-SystemHigh           system_r staff_r unconfined_r sysadm_r
staff_u         user       s0         SystemLow-SystemHigh           system_r staff_r sysadm_r
sysadm_u        user       s0         SystemLow-SystemHigh           sysadm_r
system_u        user       s0         SystemLow-SystemHigh           system_r
unconfined_u    unconfined s0         SystemLow-SystemHigh           system_r unconfined_r
user_u          user       s0         s0                             user_r

mimmi> rpm -q policycoreutils libsemanage
policycoreutils-2.0.52-5.fc9
libsemanage-2.0.25-3.fc9

Note that I for various reasons don't blindly upgrade all packages on this machine immediately when they become available.  I do try to keep SELinux-related stuff pretty up-to-date, but I am a bit worried I'm fooling you by having an old version of some underlying stuff.

Could you try 

semanage login -m -s unconfined_u root

Then check the file context.

I did that, but don't see any difference, except the obvious one in "semange user -l":

mimmi> sudo semanage login -l

Inloggningsnamn           SELinux-användare        MLS/MCS-intervall        

__default__               unconfined_u              SystemLow-SystemHigh     
root                      unconfined_u              s0-s0:c0.c255            
system_u                  system_u                  SystemLow-SystemHigh     
mimmi> sudo genhomedircon
mimmi> grep '/root[^/]' /etc/selinux/targeted/contexts/files/file_contexts.homedirs
/root   -d      system_u:object_r:user_home_dir_t:s0
/root   -l      system_u:object_r:user_home_dir_t:s0
mimmi> sudo restorecon -v -F /root
mimmi> ls -lZd /root
drwxr-x---  root root system_u:object_r:user_home_dir_t /root

Created attachment 316095 [details]
Old python genhomedircon

Could you attempt to run this version of genhomedircon and see if the problem goes away.

It complains that there is no /etc/selinux/targeted/contexts/files/homedir_template.  (And indeed, there is none.)  Should there be one, and what package should it belong to?  Neither rpm nor repoquery knows about it.  Or is this some file that was part of the policy before, but isn't any more?

cp /etc/selinux/targeted/modules/active/homedir_template /etc/selinux/targeted/contexts/files/homedir_template

Ah, I should have been root when I did "locate homedir_template".

I've tried this now, and I still get entries for /root in file_contexts.homedirs

Since this was a python script, I made a bit of "print statement debugging" to see where it comes from.  From what I understand root is found among seusers by semanage_seuser_list() in selinuxConfig.getUsers().  It gets added to udict and selinuxConfig.users.  selinuxConfig.adduser explicitly excludes the other two users, system_u and __default__, but has no special case for root.

Later selinuxConfig.genoutput calls selinuxConfig.genHomeDirContext which goes through this list and writes the context.  In this phase, there are no special cases, so root is printed just like any other user.

I assume some step here does not behave as intended, but it's not obvious to me what should have been different.  Should adduser have additional explicit exclusions?

The error does not happen in Fedora 10. Can close?

I haven't seen this AVC in Fedora 10.  So in that sense the problem appears to be fixed.

But genhomedircon still generates user_home_dir_t for my /root with policycoreutils-2.0.57-11.fc10.x86_64.  Is this still a bug?  If so, maybe it really is a separate bug, which I should open a separate bugzilla for?  Daniel, what is the intended behaviour in Fedora 10 (selinux-policy-3.5.13-26.fc10.noarch)?

(In reply to comment #26)
> I haven't seen this AVC in Fedora 10.  So in that sense the problem appears to
> be fixed.

Mea culpa.  I forgot I had made a local selinux module to avoid those problems.  When I removed it, the AVC:s started appearing again.  So the problem is still there.

selinux-policy-3.5.13-40.fc10.noarch

This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  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 '9'.

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 9'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 9 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 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 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.