selinux: avc: denied { setattr } for comm="munin-cgi-graph"

Support for security such as Firewalls and securing linux
Post Reply
tedlum
Posts: 47
Joined: 2007/07/23 21:53:43

selinux: avc: denied { setattr } for comm="munin-cgi-graph"

Post by tedlum » 2017/04/27 05:05:16

So,

Code: Select all

CentOS release 6.9 (Final)
Linux munsrvp01 2.6.32-696.1.1.el6.i686 #1 SMP Tue Apr 11 16:37:48 UTC 2017 i686 i686 i386 GNU/Linux
selinux-policy.noarch                       3.7.19-307.el6
selinux-policy-targeted.noarch              3.7.19-307.el6
munin.noarch                                2.0.33-1.el6
httpd.i686                                  2.2.15-59.el6.centos

shell> semanage module -l | grep munin
munin                    1.7.0
muninlocal               1.0
munin is throwing AVC's

Code: Select all

type=AVC msg=audit(1493089265.304:20710): avc:  denied  { setattr } for  pid=7347 comm="munin-cgi-graph" name="fontconfig" dev=dm-0 ino=5791 scontext=system_u:system_r:httpd_munin_script_t:s0 tcontext=system_u:object_r:fonts_cache_t:s0 tclass=dir
which is consistent with upstream bug (from 2013)

https://bugzilla.redhat.com/show_bug.cgi?id=966635

and the upstream errata would appear to be satisfied at this point

http://rhn.redhat.com/errata/RHBA-2013-1598.html

...yet there it still is... although, that was then and this is now, and who knows what's going on this time, today.

A few minor notes
  • My AVCs are not as severe. It's just that one, not the handful on various resources seen in 966635.
  • I tried a custom policy, but not only did it not resolve the issue, audit2why admits it has no more clue than I do as to why.Actually, it did fix the issue, so what I got was a good example of running aduit2why against stale entries.

Code: Select all

module muninlocal 1.0;

require {
        type httpd_munin_script_t;
        type fonts_cache_t;
        class dir setattr;
}

#============= httpd_munin_script_t ==============
allow httpd_munin_script_t fonts_cache_t:dir setattr;

Code: Select all

type=AVC msg=audit(1493089265.304:20710): avc:  denied  { setattr } for  pid=7347 comm="munin-cgi-graph" name="fontconfig" dev=dm-0 ino=5791 scontext=system_u:system_r:httpd_munin_script_t:s0 tcontext=system_u:object_r:fonts_cache_t:s0 tclass=dir

        Was caused by:
                Unknown - would be allowed by active policy
                Possible mismatch between this policy and the one under which the audit message was generated.
The existing fcontext looks like the resource should get labeled correctly.

Code: Select all

shell> semanage fcontext -l | grep fonts_cache_t
/var/cache/fontconfig(/.*)?                        all files          system_u:object_r:fonts_cache_t:s0
...and the resource appears to be labeled.

Code: Select all

shell> ls -laZ /var/cache/fontconfig
drwxr-xr-x. root root system_u:object_r:fonts_cache_t:s0 .
drwxr-xr-x. root root system_u:object_r:var_t:s0       ..
-rw-r--r--. root root unconfined_u:object_r:fonts_cache_t:s0 12b26b760a24f8b4feb03ad48a333a72-le32d4.cache-3
I dumped the munin policy with sedismod and it looks to me like they have the setattr on the wrong scontext... or they're trying the operation with the wrong scontext... either way, this policy is never going to allow the app to do what it's trying to do, the way it's trying to do it.
<rhetorical> dare I even broach the question of why some httpd script should even need/have dir setattr on fonts_cache_t? </rhetorical>

Code: Select all

shell> grep fonts_cache_t munin.out
  allow munin_t [fonts_cache_t] : [dir] { ioctl read getattr lock search open };
  allow munin_t [fonts_cache_t] : [dir] { getattr search open };
  allow munin_t [fonts_cache_t] : [file] { ioctl read getattr lock open };
  allow munin_t [fonts_cache_t] : [dir] { getattr search open };
  allow munin_t [fonts_cache_t] : [lnk_file] { read getattr };
  allow munin_t [fonts_cache_t] : [dir] { setattr };
  allow httpd_munin_script_t [fonts_cache_t] : [dir] { ioctl read getattr lock search open };
  allow httpd_munin_script_t [fonts_cache_t] : [dir] { getattr search open };
  allow httpd_munin_script_t [fonts_cache_t] : [file] { ioctl read getattr lock open };
  allow httpd_munin_script_t [fonts_cache_t] : [dir] { getattr search open };
  allow httpd_munin_script_t [fonts_cache_t] : [lnk_file] { read getattr };
SO... I guess I have two questions... is this really a bug that needs to be reported to someone, and if so, who? ... and why didn't my policy fix it? I'm not exactly an selinux novice, but I'm obviously ignorant of some important detail. But I am stupid apparently. The muninlocal policy did fix the selinux AVC, but a munin error that was not actually caused by the policy issue led me to assume, incorrectly, that the issue had not been fixed when in fact it had.
-TIA-
Last edited by tedlum on 2017/04/27 07:05:48, edited 1 time in total.

User avatar
TrevorH
Site Admin
Posts: 33202
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: selinux: avc: denied { setattr } for comm="munin-cgi-graph"

Post by TrevorH » 2017/04/27 06:16:57

Did you put selinux permissive using setenforce 0 and then generate the full list of avcs? If you did not do that then it would stop after the first avc and not show you everything that was wrong. The second avc that you list after installing your policy module is the same one that you listed before - it has the identical timestamp - it's not a new one.

If you use service auditd rotate you can force a new audit.log to be generated then rm the other ones and recreate the problem so that only the most recent data is in the file. If there are no new avcs in permissive mode then you may be being blocked by a dontaudit rule so you can run semodule -DB to disable them, rotate the logs, run in permissive again, rerun audit2allow and see if that shows anything new. Use semodule -B to revert the dontaudit rule logging.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke

tedlum
Posts: 47
Joined: 2007/07/23 21:53:43

Re: selinux: avc: denied { setattr } for comm="munin-cgi-graph"

Post by tedlum » 2017/04/27 07:15:00

Yes I had run it permissive to be sure that was all of them. What I failed to notice was that I eventually patched the policy problem with my muninlocal policy... munin still had the same error, but that turned out to not be related to the setattr.

But what I've done is patch my instance. The package is still broken though. I think this comes from EPEL, but RHEL seems to take bug reports on it. Who needs to know about this?

User avatar
TrevorH
Site Admin
Posts: 33202
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: selinux: avc: denied { setattr } for comm="munin-cgi-graph"

Post by TrevorH » 2017/04/27 12:14:32

Bugs in EPEL packages get reported on bugzilla.redhat.com in the Fedora EPEL section.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke

tedlum
Posts: 47
Joined: 2007/07/23 21:53:43

Re: selinux: avc: denied { setattr } for comm="munin-cgi-graph"

Post by tedlum » 2017/04/27 17:17:47

Just to maintain continuity for this issue: https://bugzilla.redhat.com/show_bug.cgi?id=1446331

It probably goes without saying that a local policy needs to be used until the package issue is addressed.

Also, there was a secondary issue where the /var/lib/munin acls did not allow apache to dynamically create and manage the cgi-tmp directory. Once that was corrected the AVCs got a whole lot worse because the process was able to go a lot further, so an appropriate local policy would look more like this:

Code: Select all

#============= httpd_munin_script_t ==============
allow httpd_munin_script_t fonts_cache_t:dir setattr;
allow httpd_munin_script_t munin_var_lib_t:dir { write remove_name add_name };
allow httpd_munin_script_t munin_var_lib_t:file { write create unlink setattr };
I would seriously recommend that anyone who encounters a similar issue only take what they see here under advisement, but generate their own local policy with audit2allow.

Post Reply