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.
