at a loss with a problem: munin-node df

Hi all,

I'm quite at a loss with this one and would be thankful if somebody
could point out where my thinking is wrong and possibly what would be
the most appropriate way to fix the issue.

I've got a F12 machine with httpd, git and munin (server and node)
installed. Things work fine except that munin-node gets an avc denied
when running df.

Running 'munin-run df' on the command line works fine, but telnetting to
port 4949 and issuing the command 'fetch df', which should basically do
the same, returns a '# Bad exit' message and the following selinux logs:

  type=AVC msg=audit(1269984513.464:737891): avc:  denied  { search } for  pid=29383
comm="df" name="git" dev=vdb1 ino=918433
scontext=unconfined_u:system_r:munin_t:s0
tcontext=system_u:object_r:httpd_git_content_t:s0 tclass=dir
  type=SYSCALL msg=audit(1269984513.464:737891): arch=c000003e syscall=137 success=yes
exit=128 a0=b32df0 a1=7fffc9958bf0 a2=7fffc9959490 a3=3237e7ea20 items=0 ppid=29382
pid=29383 auid=0 uid=801 gid=801 euid=801 suid=801 fsuid=801 egid=801 sgid=801 fsgid=801
tty=(none) ses=13057 comm="df" exe="/bin/df"
subj=unconfined_u:system_r:munin_t:s0 key=(null)

user and group 801 are the munin user:

  # getent passwd 801
  munin:x:801:801:Munin user:/var/lib/munin:/sbin/nologin
  # getent group 801
  munin:x:801:

inode 918433 is the directory /var/www/git on /dev/vd1:

  # ls -ldi /var/www/git
  918433 drwxr-xr-x. 3 root root 4096 2010-03-27 20:12 /var/www/git
  # df -h /var/www /var/www/git/repos
  Filesystem            Size  Used Avail Use% Mounted on
  /dev/vdb1              20G   12G  6.8G  64% /var/www
  /dev/vde1              20G  4.4G   15G  24% /var/www/git/repos

As can be seen above, /var/www/git/repos is a mountpoint. It does have
the same context as /var/www/git, as well as a few more items:

  # find /var/www -context "system_u:object_r:httpd_git_content_t:s0" -ls 
  918433    4 drwxr-xr-x   3 root     root         4096 Mar 27 20:12 /var/www/git
  919158    4 -rw-r--r--   1 root     root          115 Dec 24 00:00
/var/www/git/git-favicon.png
  919159    4 -rw-r--r--   1 root     root          207 Dec 24 00:00
/var/www/git/git-logo.png
  919161   12 -rw-r--r--   1 root     root         8379 Dec 24 00:00
/var/www/git/gitweb.css
       2    4 dr-xr-xr-x  21 autocheckout autocheckout     4096 Feb 23 22:06
/var/www/git/repos
      11   16 drwx------   2 root     root        16384 Feb  8 20:00
/var/www/git/repos/lost+found

The port, which munin-node is listening on, is labelled with
munin_port_t, which is, I believe, the reason things work from the
command line but not via the network:

  # semanage port -l | grep 4949
  munin_port_t                   tcp      4949
  munin_port_t                   udp      4949

Up to here I still understand things, by connecting to port 4949 my
connection gets the context munin_t and somehow that is not allowed
to do a search on httpd_git_content_t. The following test-policy in
fact would take care of this problem (tested):

  policy_module(kktest,0.0.1)
  
  require {
          type munin_t;
          type httpd_git_content_t;
  };
  
  bool allow_kktest false;
  if (allow_kktest) {
    allow munin_t httpd_git_content_t : dir { search } ;
  } else {
  };

But what I simply cannot understand is why I do not get any avc
denials, even without my test policy module, in the following two
cases:

1) By changing the type of /var/www/git to something else,
   like httpd_sys_content_t:

     chcon -t httpd_sys_content_t /var/www/git

   I still have other directories with the same type /var/www/git
   previously had and they don't cause any problem.

2) By leaving /var/www/git at type httpd_git_content_t, which normally
   causes the problems, but umounting the filesystem below it:

    umount /var/www/git/repos

What the heck am I missing? And would my test module not merely be a
working but also a correct solution? (Guess I could answer the second
question myself, once I get the first mistery solved.)

Thanks a lot,

Kurt

-- 
----------------------------------------------------------------------
: Kurt(a)pinboard.com          http://www.pinboard.com/       business :
:                            http://kurt.www.pinboard.com/  private  :
----------------------------------------------------------------------
:                    Unix and Internet Specialist                    :
: PGP fingerprint 7D6F 672A D30C CB86 30F3  88E4 194C 9BCB C382 DC4A :
----------------------------------------------------------------------

[Daniel J Walsh]

On 03/30/2010 06:10 PM, pbdlists(a)pinboard.com wrote:
>  Hi all,
>
>  I'm quite at a loss with this one and would be thankful if somebody
>  could point out where my thinking is wrong and possibly what would be
>  the most appropriate way to fix the issue.
>
>  I've got a F12 machine with httpd, git and munin (server and node)
>  installed. Things work fine except that munin-node gets an avc denied
>  when running df.
>
>  Running 'munin-run df' on the command line works fine, but telnetting to
>  port 4949 and issuing the command 'fetch df', which should basically do
>  the same, returns a '# Bad exit' message and the following selinux logs:
>
>     type=AVC msg=audit(1269984513.464:737891): avc:  denied  { search } for  pid=29383
> comm="df" name="git" dev=vdb1 ino=918433
> scontext=unconfined_u:system_r:munin_t:s0
> tcontext=system_u:object_r:httpd_git_content_t:s0 tclass=dir
>     type=SYSCALL msg=audit(1269984513.464:737891): arch=c000003e syscall=137 success=yes
> exit=128 a0=b32df0 a1=7fffc9958bf0 a2=7fffc9959490 a3=3237e7ea20 items=0 ppid=29382
> pid=29383 auid=0 uid=801 gid=801 euid=801 suid=801 fsuid=801 egid=801 sgid=801 fsgid=801
> tty=(none) ses=13057 comm="df" exe="/bin/df"
> subj=unconfined_u:system_r:munin_t:s0 key=(null)
>
>  user and group 801 are the munin user:
>
>     # getent passwd 801
>     munin:x:801:801:Munin user:/var/lib/munin:/sbin/nologin
>     # getent group 801
>     munin:x:801:
>
>  inode 918433 is the directory /var/www/git on /dev/vd1:
>
>     # ls -ldi /var/www/git
>     918433 drwxr-xr-x. 3 root root 4096 2010-03-27 20:12 /var/www/git
>     # df -h /var/www /var/www/git/repos
>     Filesystem            Size  Used Avail Use% Mounted on
>     /dev/vdb1              20G   12G  6.8G  64% /var/www
>     /dev/vde1              20G  4.4G   15G  24% /var/www/git/repos
>
>  As can be seen above, /var/www/git/repos is a mountpoint. It does have
>  the same context as /var/www/git, as well as a few more items:
>
>     # find /var/www -context "system_u:object_r:httpd_git_content_t:s0" -ls
>     918433    4 drwxr-xr-x   3 root     root         4096 Mar 27 20:12 /var/www/git
>     919158    4 -rw-r--r--   1 root     root          115 Dec 24 00:00
> /var/www/git/git-favicon.png
>     919159    4 -rw-r--r--   1 root     root          207 Dec 24 00:00
> /var/www/git/git-logo.png
>     919161   12 -rw-r--r--   1 root     root         8379 Dec 24 00:00
> /var/www/git/gitweb.css
>          2    4 dr-xr-xr-x  21 autocheckout autocheckout     4096 Feb 23 22:06
> /var/www/git/repos
>         11   16 drwx------   2 root     root        16384 Feb  8 20:00
> /var/www/git/repos/lost+found
>
>  The port, which munin-node is listening on, is labelled with
>  munin_port_t, which is, I believe, the reason things work from the
>  command line but not via the network:
>
>     # semanage port -l | grep 4949
>     munin_port_t                   tcp      4949
>     munin_port_t                   udp      4949
>
>  Up to here I still understand things, by connecting to port 4949 my
>  connection gets the context munin_t and somehow that is not allowed
>  to do a search on httpd_git_content_t. The following test-policy in
>  fact would take care of this problem (tested):
>
>     policy_module(kktest,0.0.1)
>
>     require {
>             type munin_t;
>             type httpd_git_content_t;
>     };
>
>     bool allow_kktest false;
>     if (allow_kktest) {
>       allow munin_t httpd_git_content_t : dir { search } ;
>     } else {
>     };
>
>  But what I simply cannot understand is why I do not get any avc
>  denials, even without my test policy module, in the following two
>  cases:
>
>  1) By changing the type of /var/www/git to something else,
>      like httpd_sys_content_t:
>
>        chcon -t httpd_sys_content_t /var/www/git
>
>      I still have other directories with the same type /var/www/git
>      previously had and they don't cause any problem.
>
>  2) By leaving /var/www/git at type httpd_git_content_t, which normally
>      causes the problems, but umounting the filesystem below it:
>
>       umount /var/www/git/repos
>
>  What the heck am I missing? And would my test module not merely be a
>  working but also a correct solution? (Guess I could answer the second
>  question myself, once I get the first mistery solved.)
>
>  Thanks a lot,
>
>  Kurt
>
>      
df is searching through all of the toplevel mountpoint directories, df 
does not search through any of the subdirectories.

If the top level directory is labeled httpd_sys_content_t, munin_t has 
policy that allows it to search.

# sesearch -A -s munin_t -t httpd_sys_content_t -c dir
Found 2 semantic av rules:
    allow daemon httpd_sys_content_t : dir { getattr search open } ;
    allow munin_t httpd_sys_content_t : dir { getattr search open } ;

If the directory is labeled httpd_git_content_t, there is no rule to 
allow git to search.

# sesearch -A -s munin_t -t httpd_git_content_t -c dir


Your custom policy does not need a boolean.  I would just add

     allow munin_t httpd_git_content_t : dir { search getattr };

And you are done.

On Wed, Mar 31, 2010 at 09:18:38AM -0400, Daniel J Walsh wrote:

>  df is searching through all of the toplevel mountpoint directories,
> df 
>  does not search through any of the subdirectories. 
Ok, that would explain the behaviour (even though I don't see why it
would access the _parent_ directory; all I can see in strace output is a
statfs call directly to the mounted directory. But maybe I don't need to
completely understand everything.)

>  Your custom policy does not need a boolean.  I would just add 
Yep. It's just what I usually do while I'm still testing things, so I
can more easily switch it on and off at will.

Thank you very much for sheding light to where I had a dark spot.

Kurt