[refpolicy] refpolicy-2.20101213 (mcs) and dbus messages

[guido@trentalancia.com (Guido Trentalancia)]

On Fri, 14/01/2011 at 15.36 +0100, Dominick Grift wrote:
> >> Strange, in that case i guess you will have to translate it manually.
> >>
> >> 1.
> >>
> >> AVC denial:
> >>
> >>>> denied  { send_msg } for msgtype=method_call
> >>>> interface=org.freedesktop.Hal.Manager member=FindDeviceByCapability
> >>>> dest=org.freedesktop.Hal spid=2928 tpid=2314
> >>>> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
> >>>> tcontext=system_u:system_r:hald_t:s0 tclass=dbus :
> >>>> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
> >>
> >> Raw policy:
> >>
> >> allow xdm_t hald_t:dbus send_msg;
> >>
> >> Possible macro/interface:
> >>
> >> hal_dbus_chat(xdm_t)
> >>
> >> 2.
> >>
> >>>> denied  { send_msg } for msgtype=signal
> >>>> interface=org.freedesktop.PolicyKit1.Authority member=Changed
> >>>> dest=org.freedesktop.DBus spid=2613 tpid=2546
> >>>> scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
> >>>> tcontext=system_u:system_r:consolekit_t:s0-s0:c0.c1023 tclass=dbus :
> >>>> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
> >>>>
> >>
> >> Raw policy:
> >>
> >> allow system_dbusd_t consolekit_t:dbus send_msg;
> >>
> >> Possible macro/interface:
> >>
> >> consolekit_dbus_chat(system_dbusd_t)
> >>
> >> 3.
> >>
> >>>> denied  { send_msg } for msgtype=method_call
> >>>> interface=org.freedesktop.DBus.Properties member=GetAll
> >>>> dest=org.freedesktop.UDisks spid=3567 tpid=3569
> >>>> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
> >>>> tcontext=system_u:system_r:devicekit_disk_t:s0-s0:c0.c1023 tclass=dbus :
> >>>> exe="/bin/dbus-daemon" sauid=81 hostname=? addr=?
> >>>> terminal=?'
> >>
> >> Raw policy:
> >>
> >> allow xdm_t devicekit_disk_t:dbus send_msg;
> >>
> >> Possible macro/interface:
> >>
> >> devicekit_dbus_chat_disk(xdm_t)

Yes, the new modules work perfectly ! We absolutely need to get this
stuff upstreamed into the next refpolicy (see also last point of this
message).

> > By the way, I have also noticed that for some reason user_dmesg is not
> > being effectively enforced. The user_dmesg boolean is set to false, the
> > dmesg module is loaded, the system is in enforcing mode, still a normal
> > user is able to use dmesg...
> 
> "Normal" users are not constraint by user_dmesg i believe. Its only for
> restricted users

Fair play then. I think the latest kernel 2.6.37 might have something
new from that point of view (CONFIG_SECURITY_DMESG_RESTRICT) but I had
no time to check it through-fully.

> > And last but not least, I have already mentioned about a few graphical
> > applications that refuse to start without leaving any trace in the logs.
> > Namely these are: gnome-terminal, gedit, evince and openoffice (not the
> > execstack issue in this last case). What can be done if nothing appears
> > in the logs ? How do I get to know what has been denied ?
> 
> semodule -DB to unload hidden denial rules
> semodule -B to re-insert hidden denial rules

Everything has been sorted out now. So everything was just depending on
dbus messages not being sent.

I shall really produce a patch in terms of policy as soon as possible.

All the best,

Guido