Bug 447048 - SELinux is preventing the mrtg from using potentially mislabeled files (./root).
SELinux is preventing the mrtg from using potentially mislabeled files (./root).
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: policycoreutils (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-17 08:36 EDT by Mauricio Teixeira
Modified: 2009-07-14 13:54 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 13:54:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
SELinux alert report for version 3.3.1-62.fc9 (2.73 KB, text/plain)
2008-06-06 13:42 EDT, Joachim Frieben
no flags Details
Old python genhomedircon (11.35 KB, application/octet-stream)
2008-09-08 12:02 EDT, Daniel Walsh
no flags Details

  None (edit)
Description Mauricio Teixeira 2008-05-17 08:36:52 EDT
The error bellow happens because of the /etc/cront.d/mrtg being enabled at
install time, and no useful configuration has been done.

--------

Summary:

SELinux is preventing the mrtg from using potentially mislabeled files (./root).

Detailed Description:

[SELinux is in permissive mode, the operation would have been denied but was
permitted due to permissive mode.]

SELinux has denied mrtg access to potentially mislabeled file(s) (./root). This
means that SELinux will not allow mrtg to use these files. It is common for
users to edit files in their home directory or tmp directories and then move
(mv) them to system directories. The problem is that the files end up with the
wrong file context which confined applications are not allowed to access.

Allowing Access:

If you want mrtg to access this files, you need to relabel them using restorecon
-v './root'. You might want to relabel the entire directory using restorecon -R
-v './root'.

Additional Information:

Source Context                system_u:system_r:mrtg_t:s0-s0:c0.c1023
Target Context                system_u:object_r:admin_home_t:s0
Target Objects                ./root [ dir ]
Source                        mrtg
Source Path                   /usr/bin/perl
Port                          <Unknown>
Host                          mteixeira.homelinux.net
Source RPM Packages           perl-5.10.0-20.fc9
Target RPM Packages           filesystem-2.4.13-1.fc9
Policy RPM                    selinux-policy-3.3.1-42.fc9
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Permissive
Plugin Name                   home_tmp_bad_labels
Host Name                     mteixeira.homelinux.net
Platform                      Linux mteixeira.homelinux.net 2.6.25-14.fc9.x86_64
                              #1 SMP Thu May 1 06:06:21 EDT 2008 x86_64 x86_64
Alert Count                   89
First Seen                    Wed May 14 20:05:02 2008
Last Seen                     Sat May 17 09:35:01 2008
Local ID                      39bad57b-ba6e-435a-813f-3d02d782b3d6
Line Numbers                  

Raw Audit Messages            

host=mteixeira.homelinux.net type=AVC msg=audit(1211027701.748:8953): avc: 
denied  { read } for  pid=25862 comm="mrtg" name="root" dev=sda6 ino=1001377
scontext=system_u:system_r:mrtg_t:s0-s0:c0.c1023
tcontext=system_u:object_r:admin_home_t:s0 tclass=dir

host=mteixeira.homelinux.net type=SYSCALL msg=audit(1211027701.748:8953):
arch=c000003e syscall=2 success=yes exit=5 a0=11258b a1=0 a2=4000
a3=7fff627461c0 items=0 ppid=25859 pid=25862 auid=0 uid=0 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1552 comm="mrtg"
exe="/usr/bin/perl" subj=system_u:system_r:mrtg_t:s0-s0:c0.c1023 key=(null)
Comment 1 Joachim Frieben 2008-06-06 13:42:03 EDT
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.
Comment 2 Daniel Walsh 2008-06-24 06:21:41 EDT
Does this happen when you execute service mrtg start while sitting in /root or
does it happen on boot?
Comment 3 Daniel Walsh 2008-06-24 06:27:40 EDT
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
Comment 4 Göran Uddeborg 2008-08-26 06:03:23 EDT
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
Comment 5 Daniel Walsh 2008-09-02 16:43:49 EDT
# restorecon -R -v /root

Does this fix the problem?
Comment 6 Göran Uddeborg 2008-09-02 16:49:33 EDT
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.)
Comment 7 Daniel Walsh 2008-09-03 15:45:34 EDT
What does 

matchpathcon /root 

Say?
Comment 8 Göran Uddeborg 2008-09-03 16:17:35 EDT
22:16 freddi$ sudo matchpathcon /root
/root   system_u:object_r:user_home_dir_t
Comment 9 Daniel Walsh 2008-09-03 16:55:40 EDT
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
Comment 10 Göran Uddeborg 2008-09-03 17:24:51 EDT
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.)
Comment 11 Daniel Walsh 2008-09-03 18:04:03 EDT
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?
Comment 12 Göran Uddeborg 2008-09-04 02:38:50 EDT
> 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
Comment 13 Daniel Walsh 2008-09-04 09:59:33 EDT
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
Comment 14 Göran Uddeborg 2008-09-04 10:41:51 EDT
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.)
Comment 15 Daniel Walsh 2008-09-05 11:31:00 EDT
Yes but this has got me baffled.  I will take a look at the code.
Comment 16 Daniel Walsh 2008-09-05 11:36:52 EDT
What does 
# semanage login -l 
and
# semanage user -l

output?
Comment 17 Daniel Walsh 2008-09-05 11:57:27 EDT
rpm -q policycoreutils libsemanage
Comment 18 Göran Uddeborg 2008-09-05 16:06:08 EDT
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.
Comment 19 Daniel Walsh 2008-09-08 10:17:23 EDT
Could you try 

semanage login -m -s unconfined_u root

Then check the file context.
Comment 20 Göran Uddeborg 2008-09-08 10:31:41 EDT
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
Comment 21 Daniel Walsh 2008-09-08 12:02:55 EDT
Created attachment 316095 [details]
Old python genhomedircon

Could you attempt to run this version of genhomedircon and see if the problem goes away.
Comment 22 Göran Uddeborg 2008-09-08 12:16:05 EDT
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?
Comment 23 Daniel Walsh 2008-09-08 16:34:29 EDT
cp /etc/selinux/targeted/modules/active/homedir_template /etc/selinux/targeted/contexts/files/homedir_template
Comment 24 Göran Uddeborg 2008-09-09 05:39:48 EDT
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?
Comment 25 Mauricio Teixeira 2008-12-02 17:18:57 EST
The error does not happen in Fedora 10. Can close?
Comment 26 Göran Uddeborg 2008-12-28 06:38:39 EST
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)?
Comment 27 Göran Uddeborg 2009-02-05 13:04:10 EST
(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
Comment 28 Bug Zapper 2009-06-09 20:55:48 EDT
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
Comment 29 Bug Zapper 2009-07-14 13:54:53 EDT
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.

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