From: guido@trentalancia.com (Guido Trentalancia)
Date: Fri, 14 Jan 2011 15:27:52 +0100
Subject: [refpolicy] refpolicy-2.20101213 (mcs) and dbus messages
In-Reply-To: <4D301895.3050409@gmail.com>
References: <1294867930.1731.34.camel@tesla.lan>
	<4D2EC398.7060304@gmail.com> <1294921531.3112.18.camel@tesla.lan>
	<4D2EF14E.8020903@gmail.com> <1294931759.3153.25.camel@tesla.lan>
	<4D2F1C7B.5040206@gmail.com> <1294946652.2985.19.camel@tesla.lan>
	<4D2F590C.8000005@gmail.com> <1294954622.3100.11.camel@tesla.lan>
	<4D2F71E7.7030901@gmail.com> <1294960535.3100.14.camel@tesla.lan>
	<4D301895.3050409@gmail.com>
Message-ID: <1295015272.3119.14.camel@tesla.lan>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

Hello Dominick !

On Fri, 14/01/2011 at 10.34 +0100, Dominick Grift wrote:
> > Hi Dominick !
> > 
> > On Thu, 13/01/2011 at 22.43 +0100, Dominick Grift wrote:
> >>> But in general for USER_AVCs there is nothing like audit2allow that can
> >>> be used to ease the job ?
> >>
> >> audit2allow can also be used for these dbus AVC' s sure. But if you want
> >> this stuff upstreamed then you will have to play by upstreams rules
> >> (style rules)
> > 
> > No, apparently audit2allow doesn't do the job for USER_AVCs.
> 
> 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)
> 
> 
> But this is only the start, You will probably encounter many more policy
> issues. You will need to be able to analyse them and resolve issues
> accordingly.

Wonderful ! I was not trying to get the job done, but a starting point
is indeed very useful, since I have never done anything apart from a few
trivial modules with the help of audit2allow.

Rushing to check if the new modules work. Then starting from there, I
could create and submit a patch which allows those and any other
permission that would be needed.

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...

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 ?

Thanks very much for your time. Much appreciated !

Kind regards,

Guido