I am getting tons of these messages since I updated to 4.2
Nov 12 12:21:39 srv1 dbus: Can't send to audit system: USER_AVC pid=2839
uid=81 loginuid=-1 message=avc: denied { send_msg } for
scontext=user_u:system_r:unconfined_t tcontext=user_u:system_r:initrc_t
tclass=dbus
Now I can see this process...
# ps aux|grep 2839
dbus 2839 0.0 0.3 16168 1888 ? Ssl Nov11 0:13 dbus-
daemon-1 --system
root 17173 0.0 0.1 3748 668 pts/2 S+ 12:22 0:00 grep 2839
but I'm wondering how do I fix selinux so that it doesn't 'deny'
this?
Thanks
Craig
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Craig White wrote:> I am getting tons of these messages since I updated to 4.2 > > Nov 12 12:21:39 srv1 dbus: Can't send to audit system: USER_AVC pid=2839 > uid=81 loginuid=-1 message=avc: denied { send_msg } for > scontext=user_u:system_r:unconfined_t tcontext=user_u:system_r:initrc_t > tclass=dbus > > Now I can see this process... > > # ps aux|grep 2839 > dbus 2839 0.0 0.3 16168 1888 ? Ssl Nov11 0:13 dbus- > daemon-1 --system > root 17173 0.0 0.1 3748 668 pts/2 S+ 12:22 0:00 grep 2839 > > but I'm wondering how do I fix selinux so that it doesn't 'deny' this? > > Thanks > > Craig > >RHEL update 2 has introduced some changes in the audit system. Please read the release notes (kernel changes) and it'll tell you how to disable that. http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/release- \ notes/as-amd64/RELEASE-NOTES-U2-x86_64-en.html http://www.crypt.gen.nz/selinux/faq.html Good luck, -- Giovanni P. Tirloni http://blog.tirloni.org
1: SELinux is hereby invited to grow by giving pain to others, not to me. When it's ready for release to the unsuspecting world, let it be released in a 'default on' state then. Not now. 2: The word 'but' *always* indicates a denial of the statement before the 'but'. What's before the 'but' in this case is not just too important to deny, it's an understatement. SELinux is *broken* if it renders otherwise working applications dysfunctional as shipped. I don't mind being asked to volunteer to alpha/beta test software. What's done is to *compel* me to be a SELinux tester, or to disable it. Everybody who is inclined to help SELinux get ready for The Big Time Release, *please* accept my encouragement to do so. Us other miserable grunts who want to beta test something else are best off disabling SELinux as of it's current behavior. "It's needed for security" meets the "necessary" test, but not the "proper" test, which won't be met until it works without breaking things. Brian Brunner brian.t.brunner at gai-tronics.com (610)796-5838>>> jperrin at gmail.com 11/14/05 09:29AM >>>SELinux is going through growing pains, and it's not quite to the point where I'd call it "user friendly", but ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.hubbell.com - Hubbell Incorporated
How do we define Ready? I gave that answer in the text you replied to: when it doesn't break things. You ask about applications not being SELinux aware. The proper things for SELinux to do in those cases is advise the operator that SELinux can't manage this app because it isn't SELinux aware, and that whatever security holes that application embodies are outside the scope of SELinux. This is consistent with SELinux being a *service* to the operator, not a bully-boss to the operator and the authors/maintainers of every package Joe Operator might have on his system.>> SELinux is *broken* if it renders otherwise working >> applications dysfunctional as shipped.> Depends on your viewpoint.No, it doesn't. It's about ownership of control. Is this RedHats' system to break if they want to compel me to do things their way? If not, then distributing SELinux with a default of 'on' when it breaks running systems is distributing a broken software package.>SELinux works. It's just that most software isn't designed > with it in mind. ;->Translate: Everybody is out of step except my boy! (and those who happen to be in step with him). I say Broken, and Disabled for Good. The proper things for SELinux to do in cases of non-compliant apps is to advise the operator that SELinux can't manage this app because it isn't SELinux aware, and that whatever security holes that application embodies are outside the scope of SELinux. That's a *service*. Breaking said applications is a broken application. Brian Brunner brian.t.brunner at gai-tronics.com (610)796-5838>>> thebs413 at earthlink.net 11/14/05 10:49AM >>>"Brian T. Brunner" <brian.t.brunner at gai-tronics.com> wrote:> 1: SELinux is hereby invited to grow by giving pain to > others, not to me. When it's ready for release to the > unsuspecting world, let it be released in a 'default on' > state then. Not now.How do you define "ready"??? Do we wait until all software is SELinux-aware? Do we wait until all sysadmins know how to use it? Same problems with ... NPTL ANSI C++ GLibC 2 and many others. Red Hat is forcing people to adopt it, so people have to comply. Because if they don't, they won't. And then it will _never_ be "ready."> SELinux is *broken* if it renders otherwise working > applications dysfunctional as shipped.Depends on your viewpoint. The same was said about NPTL, ANSI C++ and GLibC 2. Yet Red Hat regression tests _all_ its distros as a whole before shipment. It verifies things work as they should. That was true of the first Red Hat distro with NPTL, the first distro with ANSI C++ compliant compilers and code, with GLibC 2. But then people configure things, use them in ways that aren't stock, and things start to break. And the biggest culprit is legacy software that isn't compatible or compliant. Who's at fault then? In the end, it's not about "fault" and it's not about "broken." By the same definition, _real_ firewalls that do outgoing as well as incoming blocking are "broken" as well. Furthermore, the same could be said for higher-layer IDS/IPS systems. Red Hat always forces the issue. They get chastized for it. Their software and/or defaults get declared as broken, etc..., etc..., etc... In fact, I distinctly remember a major complaint about Red Hat taking off suid on cdrecord, which forced people to use proper permissions on the devices. That was also, so-called, "broken." But then, Red Hat had only one of the very few distros without the kernel 2.8.1.x priority issue (because cdrecord didn't run suid). So who was "broken" there? It's all a matter of viewpoint.> I don't mind being asked to volunteer to alpha/beta test > software. What's done is to *compel* me to be a SELinux > tester, or to disable it. Everybody who is inclined to > help SELinux get ready for The Big Time Release, *please* > accept my encouragement to do so.SELinux is already "The Big Time" -- but the majority of software on Linux is not. At some point, _someone_ has to get people to care. SELinux works. It's just that most software isn't designed with it in mind. ;->> Us other miserable grunts who want to beta test something > else are best off disabling SELinux as of it's current > behavior. > "It's needed for security" meets the "necessary" test, but > not the "proper" test, which won't be met until it works > without breaking things.Then you're going to be waiting _forever_. Just like most people don't do "deny all outgoing" firewalls either. They don't want have to deal with things. I hate these meta-discussions. But I guess I'm tired of seeing "compatibility issues" mistaken for "broken." SELinux throws a wrench into a lot of programs that should be written differently, and no amount of "SELinux hacking" is going to be a "workaround" for some programs/configurations. The mindset has to change. Otherwise, you will _never_ get something like SELinux to work. And Linux won't be able to reach higher CC levels. -- Bryan J. Smith | Sent from Yahoo Mail mailto:b.j.smith at ieee.org | (please excuse any http://thebs413.blogspot.com/ | missing headers) _______________________________________________ CentOS mailing list CentOS at centos.org http://lists.centos.org/mailman/listinfo/centos ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.hubbell.com - Hubbell Incorporated
On Sat, 12 Nov 2005, Craig White wrote:> I am getting tons of these messages since I updated to 4.2 > > Nov 12 12:21:39 srv1 dbus: Can't send to audit system: USER_AVC pid=2839 > uid=81 loginuid=-1 message=avc: denied { send_msg } for > scontext=user_u:system_r:unconfined_t tcontext=user_u:system_r:initrc_t > tclass=dbus > > Now I can see this process... > > # ps aux|grep 2839 > dbus 2839 0.0 0.3 16168 1888 ? Ssl Nov11 0:13 dbus- > daemon-1 --system > root 17173 0.0 0.1 3748 668 pts/2 S+ 12:22 0:00 grep 2839 > > but I'm wondering how do I fix selinux so that it doesn't 'deny' this?I sent the below to the selinux list and got the following response: Date: Mon, 24 Oct 2005 14:06:36 -0400 From: Daniel J Walsh <dwalsh at redhat.com> To: Tom Diehl <tdiehl at rogueind.com> Cc: fedora-selinux-list at redhat.com Subject: Re: AVC message problem Tom Diehl wrote:> On Mon, 24 Oct 2005, Daniel J Walsh wrote: > > >> Tom Diehl wrote: >> >>> Hi all, >>> >>> Since upgrading to EL4-U2 I am getting the following avc messages in my logs: >>> >>> Oct 23 14:46:21 pocono dbus: Can't send to audit system: USER_AVC pid=3064 uid=81 loginuid=-1 message=avc: denied {send_msg } for scontext=user_u:system_r:unconfined_t tcontext=user_u:system_r:initrc_t tclass=dbus>>> >>> Can someone tell me how to go about fixing this, short of turning off selinux? >>> >>> (pocono pts13) # rpm -qa | grep selinux >>> libselinux-1.19.1-7 >>> libselinux-1.19.1-7 >>> selinux-policy-targeted-1.17.30-2.110 >>> libselinux-devel-1.19.1-7 >>> (pocono pts13) # rpm -qa dbus >>> dbus-0.22-12.EL.5 >>> (pocono pts13) # uname -r >>> 2.6.9-22.ELsmp >>> (pocono pts13) # >>> >>> I get hundreds of these a day. I have tried relabeling but no change. >>> >>> The system arch is x86_64 >>> >>> >> Could you try >> > > Yep > > >> ftp://people.redhat.com/dwalsh/SELinux/RHEL4/u3/selinux-policy-targeted-* >> >> We are moving to deliver an errata release of this policy. >> > > I did the following: > > (pocono pts18) # rpm -Fvh selinux-policy-targeted-1.17.30-2.117.noarch.rpm > Preparing... ########################################### [100%] > 1:selinux-policy-targeted########################################### [100%] > (pocono pts18) # > > So far no more avc messages. They were showing up every 5-15 seconds > before. It has been approx 5 minutes with no avc messages. > > Is there anything else I should be looking at? > >Nope it should all work now.> Is there a bug for this? >Yes, hopefully we will release this as an errata, It will definitely be in U3.> Thank You for the help.The above rpm fixed it for me, although I still do not understand the problem. :-) Regards, Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com
Fixing it isn't my job, that's why! I got other strange fish to fry (like the frigging compiler), if SELinux *couldn't* be disabled, that would inspire an immediate decision to drop the distro. cold. Fix it if it pleases you to do so, *please* understand I'm plenty busy with the things I'm paid to do, and have *my* *own* hobbies & distractions for the free time. When SELinux is ready for The Big Time (meaning it doesn't break other apps), ship it my way! Brian Brunner brian.t.brunner at gai-tronics.com (610)796-5838>>> tdiehl at rogueind.com 11/14/05 10:14PM >>>although I fail to see how anyone expects it to ever get fixed if no one will even try to use it. ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.hubbell.com - Hubbell Incorporated