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

[domg472@gmail.com (Dominick Grift)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/14/2011 03:27 PM, Guido Trentalancia wrote:
> 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...

"Normal" users are not constraint by user_dmesg i believe. Its only for
restricted users


> 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

> 
> Thanks very much for your time. Much appreciated !
> 
> Kind regards,
> 
> Guido
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk0wX4gACgkQMlxVo39jgT+PcACfT7ohHpirGqsXeFQUdyrgThMQ
1mYAn38spGu2TaHpxSxxgAaD4KQCFg+S
=Z3rQ
-----END PGP SIGNATURE-----