I'm getting selinux denials with a default install of mrtg. I found a bug opened/ and closed notabug: https://bugzilla.redhat.com/show_bug.cgi?id=439953
However, that relates to a custom user config that calls a script, and the response was that matching policy needs to be built.
In my case mrtg is running completely default {which may well be fully useless - I haven't learnt enough about it yet}.
Should there be selinux denials on a default install of a package ?
DaveT.
David Timms wrote:
Should there be selinux denials on a default install of a package ?
audit item attached.
DT.
Summary:
SELinux is preventing mrtg (mrtg_t) "read" to ./root (user_home_dir_t).
Detailed Description:
SELinux denied access requested by mrtg. It is not expected that this access is required by mrtg and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access.
Allowing Access:
Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for ./root,
restorecon -v './root'
If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package.
Additional Information:
Source Context system_u:system_r:mrtg_t:SystemLow-SystemHigh Target Context system_u:object_r:user_home_dir_t Target Objects ./root [ dir ] Source mrtg Source Path /usr/bin/perl Port <Unknown> Host poweredge 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-31.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name poweredge Platform Linux poweredge 2.6.25-0.195.rc8.git1.fc9.i686 #1 SMP Thu Apr 3 09:42:34 EDT 2008 i686 i686 Alert Count 332 First Seen Thu 10 Apr 2008 09:05:01 EST Last Seen Thu 10 Apr 2008 22:50:01 EST Local ID a045e8a5-d15b-43b2-8254-d957bc0f286d Line Numbers
Raw Audit Messages
host=poweredge type=AVC msg=audit(1207831801.359:1488): avc: denied { read } for pid=17588 comm="mrtg" name="root" dev=sda3 ino=960961 scontext=system_u:system_r:mrtg_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_dir_t:s0 tclass=dir
host=poweredge type=SYSCALL msg=audit(1207831801.359:1488): arch=40000003 syscall=5 success=no exit=-13 a0=113427 a1=8000 a2=0 a3=8000 items=0 ppid=17586 pid=17588 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=185 comm="mrtg" exe="/usr/bin/perl" subj=system_u:system_r:mrtg_t:s0-s0:c0.c1023 key=(null)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
David Timms wrote:
David Timms wrote:
Should there be selinux denials on a default install of a package ?
audit item attached.
DT.
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Your /root directory is labeled incorrectly.
restorecon -R -v /root
Should fix. That is what setroubleshoot suggested, did you try it. Default installs should not be generating AVC's
Daniel J Walsh wrote:
David Timms wrote:
David Timms wrote:
Should there be selinux denials on a default install of a package ?
audit item attached.
Your /root directory is labeled incorrectly.
I did a touch /.autorelabel and reboot yesterday morning, and made the setroubleshooter work. These have occurred since then. There is some old .xauth files from last year in the folder, but none seem to have incorrect context.
restorecon -R -v /root
Tried restorecon -R -v -n /root - there were no replies.
restorecon -R -v /root - there was also no replies. My understanding is that any files that needed their secontext restored woudl have been echoed.
Should fix. That is what setroubleshoot suggested, did you try it.
No. Is {restorecon -v './root'} the same as the above ? It does not echo any response either.
Default installs should not be generating AVC's
Does that include an upgrade F8-F9beta ?
In any case I'm doing a full relabel again, after I send this message, and I'll see if that solves it...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
David Timms wrote:
Daniel J Walsh wrote:
David Timms wrote:
David Timms wrote:
Should there be selinux denials on a default install of a package ?
audit item attached.
Your /root directory is labeled incorrectly.
I did a touch /.autorelabel and reboot yesterday morning, and made the setroubleshooter work. These have occurred since then. There is some old .xauth files from last year in the folder, but none seem to have incorrect context.
restorecon -R -v /root
Tried restorecon -R -v -n /root
- there were no replies.
restorecon -R -v /root
- there was also no replies.
My understanding is that any files that needed their secontext restored woudl have been echoed.
Should fix. That is what setroubleshoot suggested, did you try it.
No. Is {restorecon -v './root'} the same as the above ? It does not echo any response either.
Default installs should not be generating AVC's
Does that include an upgrade F8-F9beta ?
In any case I'm doing a full relabel again, after I send this message, and I'll see if that solves it...
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
No the upgrade from F8-F9 Beta will create avc's. :^(
I am working on fixing these.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
David Timms wrote:
Daniel J Walsh wrote:
David Timms wrote:
David Timms wrote:
Should there be selinux denials on a default install of a package ?
audit item attached.
Your /root directory is labeled incorrectly.
I did a touch /.autorelabel and reboot yesterday morning, and made the setroubleshooter work. These have occurred since then. There is some old .xauth files from last year in the folder, but none seem to have incorrect context.
restorecon -R -v /root
Tried restorecon -R -v -n /root
- there were no replies.
restorecon -R -v /root
- there was also no replies.
My understanding is that any files that needed their secontext restored woudl have been echoed.
Should fix. That is what setroubleshoot suggested, did you try it.
No. Is {restorecon -v './root'} the same as the above ? It does not echo any response either.
Default installs should not be generating AVC's
Does that include an upgrade F8-F9beta ?
In any case I'm doing a full relabel again, after I send this message, and I'll see if that solves it...
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
# semanage user -l # semanage login -l
Daniel J Walsh wrote:
# semanage user -l # semanage login -l
#assume DJW_REQUESTING_RESULT:
# semanage user -l Labeling MLS/ MLS/ SELinux User Prefix MCS Lvl MCS Range SELinux Roles
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
# semanage login -l Login Name SELinux User MLS/MCS Range
__default__ unconfined_u SystemLow-SystemHigh root unconfined_u SystemLow-SystemHigh system_u system_u SystemLow-SystemHigh
As an aside, I erased mrtg yesterday - mo more mrtg denials. Reinstalled mrtg just now, mrtg denials every five minutes. It is also possible that when originally installed under F8, that I attempted to configure it, but I can't find any evidence of that in /etc ...etc. My other machine doesn't popup the denials with a default install, so I expect there must be some invalid or selinux not configured to match service requirements. === Actually running same -l on another f9beta notebook: # semanage user -l {has the ones above plus:}
Labeling MLS/ MLS/ SELinux User Prefix MCS Level MCS Range SELinux Roles
guest_u guest s0 s0 guest_r xguest_u xguest s0 s0 xguest_r
# semanage login -l {same 3 items, except the selinux user for root is different}. Login Name SELinux User MLS/MCS Range
root root SystemLow-SystemHigh
Given autorelabel doesn't seem to solve it, is it worth {possible} to rpm -e the targeted policy, then reinstall it - or am I barking up the wrong tree ? =====
DaveT.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
David Timms wrote:
Daniel J Walsh wrote:
# semanage user -l # semanage login -l
#assume DJW_REQUESTING_RESULT:
# semanage user -l Labeling MLS/ MLS/ SELinux User Prefix MCS Lvl MCS Range SELinux Roles
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
# semanage login -l Login Name SELinux User MLS/MCS Range
__default__ unconfined_u SystemLow-SystemHigh root unconfined_u SystemLow-SystemHigh system_u system_u SystemLow-SystemHigh
As an aside, I erased mrtg yesterday - mo more mrtg denials. Reinstalled mrtg just now, mrtg denials every five minutes. It is also possible that when originally installed under F8, that I attempted to configure it, but I can't find any evidence of that in /etc ...etc. My other machine doesn't popup the denials with a default install, so I expect there must be some invalid or selinux not configured to match service requirements. === Actually running same -l on another f9beta notebook: # semanage user -l {has the ones above plus:}
Labeling MLS/ MLS/SELinux User Prefix MCS Level MCS Range SELinux Roles
guest_u guest s0 s0 guest_r xguest_u xguest s0 s0 xguest_r
# semanage login -l {same 3 items, except the selinux user for root is different}. Login Name SELinux User MLS/MCS Range
root root SystemLow-SystemHigh
Given autorelabel doesn't seem to solve it, is it worth {possible} to rpm -e the targeted policy, then reinstall it - or am I barking up the wrong tree ? =====
DaveT.
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Ok I looked at the bugzilla, looks like mrtg is execing top which is reading all process /proc information. Does it need to be able to read all this, or can I dontaudit it.
Daniel J Walsh wrote:
... Ok I looked at the bugzilla, looks like mrtg is execing top which is reading all process /proc information. Does it need to be able to read all this, or can I dontaudit it.
Dan, I really don't know the answer to that - I haven't got around to understanding / configuring mrtg at all. I got the impression from that bug that the poster had a specific configuration that was causing that - and that he would have to create allow rules for it to work, whereas I don't seem to have any configuration for mrtg {except what is provided in the rpm - a crond */5 min run using it's default config /etc/mrtg/mrtg.cfg
A can confirm that commenting the /etc/cron.d/mrtg command stops the denials, but I don't understand why my other F9Beta++ machine doesn't generate the same denials.
As an aside: is there a way to perform an rpm -V to verify the packages v on-disk contexts ? I could do this for mrtg and all it's requirements.
DaveT.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
David Timms wrote:
Daniel J Walsh wrote:
... Ok I looked at the bugzilla, looks like mrtg is execing top which is reading all process /proc information. Does it need to be able to read all this, or can I dontaudit it.
Dan, I really don't know the answer to that - I haven't got around to understanding / configuring mrtg at all. I got the impression from that bug that the poster had a specific configuration that was causing that - and that he would have to create allow rules for it to work, whereas I don't seem to have any configuration for mrtg {except what is provided in the rpm - a crond */5 min run using it's default config /etc/mrtg/mrtg.cfg
A can confirm that commenting the /etc/cron.d/mrtg command stops the denials, but I don't understand why my other F9Beta++ machine doesn't generate the same denials.
As an aside: is there a way to perform an rpm -V to verify the packages v on-disk contexts ? I could do this for mrtg and all it's requirements.
DaveT.
Not really but you can do a fixfiles -R mrtg restore to read the rpm database and fix the labels on disk.
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
Development discussions related to Fedora