policy issue with munin
Dominick Grift
domg472 at gmail.com
Sun Apr 3 18:14:37 UTC 2011
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/03/2011 07:29 PM, Alex wrote:
> Hi,
>
> I'm having trouble with munin on a fedora14 box and basic auth through
> apache. Included below is the selinux report I receive when trying to
> login. I have another installation where this same setup isn't a
> problem, so I'm not sure why it would be a problem here. I've followed
> the suggestions provided below to create a local policy, yet the
> problem continues.
>
> How can I troubleshoot this? Included below is the report that I received.
>
> SELinux is preventing /usr/sbin/httpd from open access on the file
> /etc/munin/htpasswd.users.
>
> ***** Plugin catchall (100. confidence) suggests ***************************
>
> If you believe that httpd should be allowed open access on the
> htpasswd.users file by default.
> Then you should report this as a bug.
> You can generate a local policy module to allow this access.
> Do
> allow this access for now by executing:
> # grep httpd /var/log/audit/audit.log | audit2allow -M mypol
> # semodule -i mypol.pp
>
> Additional Information:
> Source Context system_u:system_r:httpd_t:s0
> Target Context system_u:object_r:munin_etc_t:s0
> Target Objects /etc/munin/htpasswd.users [ file ]
> Source httpd
> Source Path /usr/sbin/httpd
> Port <Unknown>
> Host gary
> Source RPM Packages httpd-2.2.17-1.fc14
> Target RPM Packages
> Policy RPM selinux-policy-3.9.7-37.fc14
> Selinux Enabled True
> Policy Type targeted
> Enforcing Mode Enforcing
> Host Name gary
> Platform Linux alex 2.6.35.11-83.fc14.x86_64 #1 SMP Mon Feb
> 7 07:06:44 UTC 2011 x86_64 x86_64
> Alert Count 9
> First Seen Sun 03 Apr 2011 12:39:10 PM EDT
> Last Seen Sun 03 Apr 2011 12:39:20 PM EDT
> Local ID 31e62e21-19a8-44af-9555-5be1e0f704b4
>
> Raw Audit Messages
> type=AVC msg=audit(1301848760.437:29563): avc: denied { open } for
> pid=1396 comm="httpd" name="htpasswd.users" dev=sda1 ino=3543833
> scontext=system_u:system_r:httpd_t:s0
> tcontext=system_u:object_r:munin_etc_t:s0 tclass=file
How i would troubleshoot:
1. mislabeling is the most common cause for selinux errors and so this
is where i would start.
- - Reading the AVC denial above:
Source of interaction: A process with type httpd_t (and executable
file (comm=httpd) httpd)
Target of interaction: A file with type munin_etc_t (and file name
htpasswd.users)
The Troubleshoot report reveals that this file is in
/etc/munin/htpasswd.users
We could have figured this out ourselves by using the information from
the avc denial (dev=sda1 ino=3543833)
The file htpasswd.users with type munin_etc_t is at inode 3543833 on
device sda1: so we could just find its path with "find / -inum
3543833"
The i would confirm that this file is labelled correctly by running:
matchpathcon /etc/munin/htpasswd.users
If the context returns the same context as the file is currently
labelled (ls -alZ /etc/munin/htpasswd.users) then we can rule out a
labelling issue for the target in this interaction.
In theory the type for the process of the httpd command is httpd_t, so
in theory this also rules out a labelling issue for the source in this
interaction.
2. Do we have a boolean that we can toggle to allow this access:
Two ways to determine:
a. Using the audit2why command to let it suggest a solution. If it
suggests we toggle a boolean, then we could consider that solution:
echo "avc: denied { open } for pid=1396 comm="httpd"
name="htpasswd.users" dev=sda1 ino=3543833
scontext=system_u:system_r:httpd_t:s0
tcontext=system_u:object_r:munin_etc_t:s0 tclass=file" | audit2why
b. The sesearch command lets us query the policy database. We can use
it to see if there is a rule allowing httpd_t to read munin_etc_t files:
sesearch --allow -SC -s httpd_t -t munin_etc_t -c file -p open
Setroubleshoot has done all this for us already and it came to the
conclusing that there is no such rule to allow this interaction.
Provided that the source of the interaction is labelled properly we can
assume a missing TE rule in the policy database.
But just to be sure, i would like to know a little more about this
source in the interaction:
I know apache or lighttp does not need to read munin files on its own.
Thus i assume that this source if actually a web application running in
httpd's security context. This is not unusual. For example PHP
webapplications usually run as httpd_t because of the way the
interpreter works (or doesnt work). So if this webapp is a PHP webapp
then this explains it. However if this application is a CGI script then
it should probably not run in the httpd_t context type.
This could signal a mislabeling afterall or a boolean toggle issue.
I have been looking into the policy of munin and i found some
webapplication: "/var/www/html/munin/cgi"
If this is the webapp that you are running then it could be that the
scripts under that path are mislabelled, or that boolean settings
prevent httpd_t from "domain transition" to the "httpd_munin_script_t"
domain.
However, not that this matter because after some more investigation if
determined that "httpd_munin_script_t" is also not allowed to "read
(open is just the first system call needed to be able to read a file)
files with type munin_etc_t.
In conclusion:
I think it is interesting that this configuration works on one system
but not another, according to your statement. I am really wondering
whether, if true, this is due to an issue on not this but the other system.
I might be wrong though.
Here is what i advice you to do in the case that you have determined
that the rule allowing this interaction is missing:
1. Implement a rule allowing this access and see if that solves your issue:
mkdir ~/myhttpd; cd ~/myhttpd;
echo "policy_module(myhttpd, 1.0.0) optional_policy(\` gen_require(\`
type httpd_t; ') munin_read_config(httpd_t) ')" > myhttpd.te;
make -f /usr/share/selinux/devel/Makefile myhttpd.pp
(sudo/su): semodule -i myhttpd.pp
If you confirmed that this module fixes your issue (the rules allowed
httpd_t to read munin_etc_t files), then i ask you to consider reporting
a bug at bugzilla.redhat.com in the selinux-policy component for your
distro version.
>
> type=SYSCALL msg=audit(1301848760.437:29563): arch=x86_64 syscall=open
> success=no exit=EACCES a0=7f24438bde48 a1=80000 a2=1b6 a3=33 items=0
> ppid=1391 pid=1396 auid=4294967295 uid=48 gid=48 euid=48 suid=48
> fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm=httpd
> exe=/usr/sbin/httpd subj=system_u:system_r:httpd_t:s0 key=(null)
>
> Hash: httpd,httpd_t,munin_etc_t,file,open
>
> audit2allow
>
> #============= httpd_t ==============
> allow httpd_t munin_etc_t:file open;
>
> audit2allow -R
>
> #============= httpd_t ==============
> allow httpd_t munin_etc_t:file open;
> --
> selinux mailing list
> selinux at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk2YuQ0ACgkQMlxVo39jgT+9IACgno06reLzZFLDeE0F7btdtls9
3RwAoLgFiAd+Y1Xj+xyYxN0PcQuFtm+G
=Ytda
-----END PGP SIGNATURE-----
More information about the selinux
mailing list