On Fri, 2007-12-21 at 09:41 -0600, Xavier Toth wrote: > What's the difference between an AVC and a USER_AVC? The audit system distinguishes between AVC messages generated by the kernel (type=AVC) and ones generated by applications (type=USER_AVC). So USER_AVCs are from userspace object managers like dbusd or X. The send_msg permission is controlling whether the client process that connected to dbusd (as identified by the scontext) is allowed to send a message to the server process that registered the service on the bus (as identified by the tcontext). See the dbus man page. > type=USER_AVC msg=audit(1198251251.059:579): user pid=2115 uid=81 > auid=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s15:c0.c1023 > msg='avc: denied { send_msg } for msgtype=method_return dest=:1.10 > spid=2551 tpid=2987 scontext=system_u:system_r:hald_t:s0-s15:c0.c1023 > tcontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023 tclass=dbus : > exe="/bin/dbus-daemon" (sauid=81, hostname=?, addr=?, terminal=?)' > type=USER_AVC msg=audit(1198251267.173:632): user pid=2115 uid=81 > auid=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s15:c0.c1023 > msg='avc: denied { send_msg } for msgtype=method_return dest=:1.11 > spid=2243 tpid=2982 > scontext=system_u:system_r:initrc_t:s0-s15:c0.c1023 > tcontext=system_u:system_r:xdm_t:s0-s15:c0.c1023 tclass=dbus : > exe="/bin/dbus-daemon" (sauid=81, hostname=?, addr=?, terminal=?)' > type=USER_AVC msg=audit(1198251271.497:674): user pid=2115 uid=81 > auid=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s15:c0.c1023 > msg='avc: denied { send_msg } for msgtype=method_call > interface=org.freedesktop.DBus member=Hello dest=org.freedesktop.DBus > spid=3122 scontext=user_u:user_r:user_xpriv_t:s0 > tcontext=system_u:system_r:system_dbusd_t:s0-s15:c0.c1023 tclass=dbus > : exe="/bin/dbus-daemon" (sauid=81, hostname=?, addr=?, terminal=?)' > type=USER_AVC msg=audit(1198251271.520:675): user pid=2115 uid=81 > auid=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s15:c0.c1023 > msg='avc: denied { send_msg } for msgtype=method_return dest=:1.13 > spid=2551 tpid=3122 scontext=system_u:system_r:hald_t:s0-s15:c0.c1023 > tcontext=user_u:user_r:user_xpriv_t:s0 tclass=dbus : > exe="/bin/dbus-daemon" (sauid=81, hostname=?, addr=?, terminal=?)' > > > On Dec 20, 2007 3:36 PM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > > > > On Thu, 2007-12-20 at 15:11 -0600, Xavier Toth wrote: > > > dbus-daemon is running at UNCLASSIFIED-SystemHigh. A number of > > > processes running at UNCLASSIFIED (my seuers default level) are trying > > > to use dbus and getting mls constraint avcs. I'm not that familar with > > > dbus but I was thinking of changing its init script to runcon it at > > > level UNCLASSIFIED or will that just mess up other things? > > > > What are the exact avc messages in question here? > > > > There are two instances of the bus, one system-wide and one per-session, > > so you need to think about both cases. > > > > At least the system-wide bus will have to handle connections from > > clients at different levels. If you are supporting multi-level > > sessions, then the per-session bus will also have to do that. > > > > For connecting to the bus, you have to make the bus' socket a mlstrusted > > object if you want to allow any level to connect. > > > > For preventing two levels from communicating through the bus in > > violation of MLS policy, you need to write mls constraints on the dbus > > class. I don't think that has been done since the LSPP work didn't > > cover the desktop. > > > > Running the bus at unclassified will only help with the unclassified > > clients; any higher level client will then be unable to connect. > > > > -- > > Stephen Smalley > > National Security Agency > > > > > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with > the words "unsubscribe selinux" without quotes as the message. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.