Bug 481395 - mrtg-2.16.2-1.fc10.x86_64 produces two SELinux audit denials when trying to read "/root".
mrtg-2.16.2-1.fc10.x86_64 produces two SELinux audit denials when trying to r...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: mrtg (Show other bugs)
10
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Vitezslav Crhonek
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-23 19:46 EST by major
Modified: 2009-12-18 02:41 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 02:41:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
numbered crond strace for mrtg (283.53 KB, text/plain)
2009-01-23 19:46 EST, major
no flags Details

  None (edit)
Description major 2009-01-23 19:46:31 EST
Created attachment 329892 [details]
numbered crond strace for mrtg

When the mrtg cron job runs, read access is attempted to root's home directory. This generates two SELinux audit denials.

With inode 1572865 on device dm-0 corresponding to "/root", and with "user_home_dir_t" the correct default target context, the two denials were as follows.

##########
Jan 23 18:05:01 (null) (null): audit(1232755501.726:1283): avc: denied { read } for pid=30716 comm=mrtg name=root ino=1572865 dev=dm-0 scontext=system_u:system_r:mrtg_t tcontext=system_u:object_r:user_home_dir_t tclass=dir

Jan 23 18:05:01 (null) (null): audit(1232755501.727:1284): avc: denied { read } for pid=30716 comm=mrtg name=root ino=1572865 dev=dm-0 scontext=system_u:system_r:mrtg_t tcontext=system_u:object_r:user_home_dir_t tclass=dir
########## 

As the root user, I attached strace to the cron daemon, waited for the mrtg cron job to run, and captured the output (line-numbered with cat -n). (Line 2125 is a read from file descriptor 4, file "/usr/lib/perl5/5.10.0/FindBin.pm" opened on line 1944.)

##########
  2125  [pid 30716] read(4, "     {\n       my $dir;\n       for"..., 4096) = 1574
  2126  [pid 30716] stat("/usr/bin/mrtg", {st_mode=S_IFREG|0755, st_size=102195, ...}) = 0
  2127  [pid 30716] stat("/usr/bin/mrtg", {st_mode=S_IFREG|0755, st_size=102195, ...}) = 0
  2128  [pid 30716] readlink("/usr/bin/mrtg", 0x7fff0f6b9530, 4095) = -1 EINVAL (Invalid argument)
  2129  [pid 30716] open(".", O_RDONLY)         = -1 EACCES (Permission denied)
  2130  [pid 30716] open(".", O_RDONLY)         = -1 EACCES (Permission denied)
  2131  [pid 30716] read(4, ""..., 4096)        = 0
  2132  [pid 30716] close(4)                    = 0
##########

Lines 2129 and 2130 show failed opens on the current directory, which appears to refer to "./root" in the root directory, "/". Line 1380 has been edited to remove the shadowed root password. Line 1681 shows a chdir to "/root". Line 1771 shows a getcwd for "/root".
Comment 1 Vitezslav Crhonek 2009-02-09 11:00:49 EST
Hi,

I'm not able to reproduce it (with basic mrtg configuration - eth traffic statistic - from http://oss.oetiker.ch/mrtg/doc/mrtg-unix-guide.en.html).

Here's relevant part of strace on my machine:
read(4, "     {\n       my $dir;\n       for"..., 4096) = 1574
stat("/usr/bin/mrtg", {st_mode=S_IFREG|0755, st_size=102195, ...}) = 0
stat("/usr/bin/mrtg", {st_mode=S_IFREG|0755, st_size=102195, ...}) = 0
readlink("/usr/bin/mrtg", 0x7fff9ec78b40, 4095) = -1 EINVAL (Invalid argument)
open(".", O_RDONLY) = 6
chdir("/usr/bin") = 0

Directory is aslo changed to "/root", same with getcwd. That's all okay.

Is your system correctly labeled? Did you try relabel your system?
Comment 2 major 2009-02-10 00:50:35 EST
The command "matchpathcon /root" shows
##########
  /root    system_u:object_r:user_home_dir_t
##########

I am using "selinux-policy-targeted-3.5.13-41.fc10.noarch" which has "/etc/selinux/targeted/policy/policy.23".

Executing the command "sesearch --all  | grep mrtg | grep home" shows
##########
  dontaudit mrtg_t admin_home_t : file { ioctl read getattr lock } ;
  dontaudit mrtg_t admin_home_t : dir { ioctl read getattr lock search } ;
##########

Nothing on my system is labeled "admin_home_t".

I see that Bug 472285, "/root is labelled as user_home_t", Comment #2 says "This appears 'fixed' in rawhide."

Also found discussion at following URL.
##########
http://www.engardelinux.org/modules/index/list_archives.cgi?list=selinux&page=0074.html&month=2009-01
##########
Comment 3 Bug Zapper 2009-11-18 05:51:02 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  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 '10'.

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 10'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 10 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 4 Bug Zapper 2009-12-18 02:41:15 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 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.