Hi
Iam getting selinux dbus error message on my RHEL4 machine
This is different from earlier dbus error messages which is there earlier and selinux-policy-targeted-1.17.30-2.117.noarch.rpm(from Daniel walsh) has fixed it. This one looks different from that and it doesn't have "denied send_msg" message which has security class fields and helped in debugging.
Error messages looks like this =================================================================
Jan 17 17:02:07 x330b dbus: Can't send to audit system: USER_AVC pid=7704 uid=81 loginuid=0 message=avc: received policyload notice (seqno=16) Jan 17 17:02:07 x330b dbus: Can't send to audit system: USER_AVC pid=7704 uid=81 loginuid=0 message=avc: 0 AV entries and 0/512 buckets used, longest chain length 0 Jan 17 17:02:24 x330b dbus: Can't send to audit system: USER_AVC pid=7704 uid=81 loginuid=0 message=avc: received setenforce notice (enforcing=1) =================================================================== I just wanted to know,why this error message is getting generated and how to fix it out. Is it due to lack of send_msg permission?
Looking for reply Srinivasa DS
I just wanted to know,why this error message is getting generated and how to fix it out.
It would appear that dbus does not have CAP_AUDIT_WRITE permissions - which is why the message takes the form it does. However, the messages are just normal SE Linux policy load messages. To me, the question is do you just get a couple of these or does it fill the logs with it? If you just get a couple, all is well. If its filling your logs, then we should look into it more.
-Steve
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Tue, 2006-01-17 at 05:41 -0800, Steve G wrote:
I just wanted to know,why this error message is getting generated and how to fix it out.
Thanks Steve for your reply,but what I feel is,if these messages are due to CAP_AUDIT_WRITE capability problem then,adding this line to policy would have fixed the problem but that was not happening.
allow initrc_t self:capability { audit_write audit_control };
It would appear that dbus does not have CAP_AUDIT_WRITE permissions - which is why the message takes the form it does.
However, the messages are just normal SE Linux policy load messages. To me, the question is do you just get a couple of these or does it fill the logs with it? If you just get a couple, all is well. If its filling your logs, then we should look into it more.
These meesages sometimes fills log,and appears on execution of setenforce,make load and some selinux command.
-Steve
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
I feel is,if these messages are due to CAP_AUDIT_WRITE capability problem then,adding this line to policy would have fixed the problem but that was not happening.
allow initrc_t self:capability { audit_write audit_control };
There are 2 ways that the syscall can fail, MAC checks and DAC checks. The above line may help MAC checks, but does nothing for the DAC check. I have a patch in rawhide that is being tested so that when dbus changes from root to the dbus user, it retains that capability. When I'm satisfied that I haven't introduced a new bug with that patch, I'll port it to dbus in RHEL4 - maybe U4.
does it fill the logs with it? If you just get a couple, all is well.
These meesages sometimes fills log,and appears on execution of setenforce,make load and some selinux command.
There was an updated targeted policy released after U2 that should alleviate any MAC check problems. The DAC check problem shouldn't fill your logs.
-Steve
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Steve G wrote:
I feel is,if these messages are due to CAP_AUDIT_WRITE capability problem then,adding this line to policy would have fixed the problem but that was not happening.
allow initrc_t self:capability { audit_write audit_control };
There are 2 ways that the syscall can fail, MAC checks and DAC checks. The above line may help MAC checks, but does nothing for the DAC check. I have a patch in rawhide that is being tested so that when dbus changes from root to the dbus user, it retains that capability. When I'm satisfied that I haven't introduced a new bug with that patch, I'll port it to dbus in RHEL4 - maybe U4.
Thank you Steve for your reply. I heard that you already have the patch for Fedora which causes the dbus to retain capabality after changing from root to dbus user. Can you please give that patch or send the link containing the patch so that I will test it on my Fedora machine.
does it fill the logs with it? If you just get a couple, all is well.
These meesages sometimes fills log,and appears on execution of setenforce,make load and some selinux command.
There was an updated targeted policy released after U2 that should alleviate any MAC check problems. The DAC check problem shouldn't fill your logs.
-Steve
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
I heard that you already have the patch for Fedora which causes the dbus to retain capabality after changing from root to dbus user. Can you please give that patch or send the link containing the patch so that I will test it on my Fedora machine
Sure. Its here:
http://people.redhat.com/sgrubb/files/dbus-0.60-selinux-avc-audit.patch
I'll leave it there for a few days, but it'll eventually get removed.
-Steve
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
selinux@lists.fedoraproject.org