[refpolicy] [PATCH/RFC 8/19]: patch set to update the git reference policy

Thu Jan 27 14:42:18 CST 2011

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

On 01/27/2011 09:36 PM, Guido Trentalancia wrote:
> Hello Dominick !
> 
> On Thu, 27/01/2011 at 10.16 +0100, Dominick Grift wrote:
>> On 01/27/2011 01:37 AM, Guido Trentalancia wrote:
>>> On Wed, 26/01/2011 at 18.36 +0100, Dominick Grift wrote:
>>>> On 01/26/2011 06:28 PM, Guido Trentalancia wrote:
>>>>> Hello Dominick !
>>>>>
>>>>> On Wed, 26/01/2011 at 09.17 +0100, Dominick Grift wrote:
>>>>>> On 01/26/2011 01:41 AM, Guido Trentalancia wrote:
>>>>>>> On Tue, 25/01/2011 at 20.19 +0100, Dominick Grift wrote:
>>>>>>>> On 01/25/2011 08:05 PM, Guido Trentalancia wrote:
>>>>>>>>> Hi Dominick,
>>>>>>>>>
>>>>>>>>> finally I am managing to get into this...
>>>>>>>>>
>>>>>>>>> On Mon, 24/01/2011 at 15.04 +0100, Dominick Grift wrote:
>>>>>>>>>> On 01/24/2011 01:44 AM, Guido Trentalancia wrote:
>>>>>>>>>>> --- refpolicy-git-18012011-dbus-messaging/policy/modules/services/dbus.te	2011-01-23 23:13:48.168284256 +0100
>>>>>>>>>>> +++ refpolicy-git-18012011-dbus/policy/modules/services/dbus.te	2011-01-23 23:11:46.430346876 +0100
>>>>>>>>>>> @@ -52,7 +52,7 @@ ifdef(`enable_mls',`
>>>>>>>>>>>  
>>>>>>>>>>>  # dac_override: /var/run/dbus is owned by messagebus on Debian
>>>>>>>>>>>  # cjp: dac_override should probably go in a distro_debian
>>>>>>>>>>> -allow system_dbusd_t self:capability { dac_override setgid setpcap setuid };
>>>>>>>>>>> +allow system_dbusd_t self:capability { dac_override setgid setpcap setuid sys_ptrace };
>>>>>>>>>>>  dontaudit system_dbusd_t self:capability sys_tty_config;
>>>>>>>>>>>  allow system_dbusd_t self:process { getattr getsched signal_perms setpgid getcap setcap };
>>>>>>>>>>>  allow system_dbusd_t self:fifo_file rw_fifo_file_perms;
>>>>>>>>>>> @@ -111,13 +111,20 @@ auth_read_pam_console_data(system_dbusd_
>>>>>>>>>>>  corecmd_list_bin(system_dbusd_t)
>>>>>>>>>>>  corecmd_read_bin_pipes(system_dbusd_t)
>>>>>>>>>>>  corecmd_read_bin_sockets(system_dbusd_t)
>>>>>>>>>>> +# needed for system-tools-backends
>>>>>>>>>>> +corecmd_exec_shell(system_dbusd_t)
>>>>>>>>>>>  
>>>>>>>>>>>  domain_use_interactive_fds(system_dbusd_t)
>>>>>>>>>>>  domain_read_all_domains_state(system_dbusd_t)
>>>>>>>>>>>  
>>>>>>>>>>> +files_search_default(system_dbusd_t)
>>>>>>>>>>
>>>>>>>>>> There should not be able default_t type directories. Thus this shouldnt
>>>>>>>>>> be allowed
>>>>>>>>>
>>>>>>>>> Apparently, I am no longer able to find the relative log. Best thing to
>>>>>>>>> do in this case is to remove and test again.
>>>>>>>>>
>>>>>>>>>>> +files_read_default_files(system_dbusd_t)
>>>>>>>>>>
>>>>>>>>>> there should not be any default_t type files. Thus this shouldnt be allowed
>>>>>>>>>
>>>>>>>>> Same as above. Hopefully, we'll be able to get rid of that...
>>>>>>>>>
>>>>>>>>>>>  files_read_etc_files(system_dbusd_t)
>>>>>>>>>>>  files_list_home(system_dbusd_t)
>>>>>>>>>>> -files_read_usr_files(system_dbusd_t)
>>>>>>>>>>> +files_exec_bin_files(system_dbusd_t)
>>>>>>>>>>
>>>>>>>>>> Which bin_t files is it executing?
>>>>>>>>>
>>>>>>>>> I think dbus-daemon-launch-helper is executing polkitd which is labelled
>>>>>>>>> bin_t:
>>>>>>>>>
>>>>>>>>> type=AVC msg=audit(1294683706.729:33): avc:  denied
>>>>>>>>> { execute_no_trans } for  pid=2718 comm="dbus-daemon-lau"
>>>>>>>>> path="/usr/libexec/polkit-1/polkitd" dev=dm-1 ino=396675
>>>>>>>>> scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
>>>>>>>>> tcontext=system_u:object_r:bin_t:s0 tclass=file
>>>>>>>>>
>>>>>>>>
>>>>>>>> /usr/libexec/polkit-1/polkitd is labelled policykit_exec_t here. Then
>>>>>>>> one should decide whether to allow system_dbusd_t to run it in the
>>>>>>>> system_dbusd_t domain or to allow it to domain transition to policykit_t
>>>>>>>
>>>>>>> Yes, that was completely mistaken. Polkitd has now been labeled
>>>>>>> correctly and all those weird permissions have been removed from the
>>>>>>> dbus module.
>>>>>>>
>>>>>>> However, I had to create an interface policykit_can_execute() and a call
>>>>>>> to it from dbus.te so that dbus can still execute polkitd.
>>>>>>>
>>>>>>>> This depends on what dbus is doing with policykit
>>>>>>>
>>>>>>> I think D-Bus is starting polkitd. If that doesn't happen, it would not
>>>>>>> be possible to log onto the graphical interface.
>>>>>>> polkitd runs in the system_dbusd_t domain. What does refpolicy expect in
>>>>>>> this regard from the generic system it targets ?
>>>>>>>
>>>>>>
>>>>>> I guess you need to add this to policykit module:
>>>>>>
>>>>>> dbus_system_domain(policykit_t, policykit_exec_t)
>>>>>
>>>>> I am now going to test what you propose as an alternative to using a
>>>>> policykit_can_execute() interface.
>>>>>
>>>>>>>>>>> +files_exec_usr_files(system_dbusd_t)
>>>>>>>>>>
>>>>>>>>>> Which usr_t files is it executing?
>>>>>>>>>
>>>>>>>>> It's needed to execute a perl script from system-tools-backends (version
>>>>>>>>> 2.10.1) which is located at:
>>>>>>>>>
>>>>>>>>> /usr/share/system-tools-backends-2.0/scripts/SystemToolsBackends.pl
>>>>>>>>>
>>>>>>>>
>>>>>>>> This could be labelled bin_t. Maybe even write policy for it if
>>>>>>>> applicable (probably a good idea so that we do not have to allow
>>>>>>>> system_dbusd_t to run bin_t files (corecmd_exec_bin)
>>>>>>>>
>>>>>>>> What package does this file belong to?
>>>>>>>
>>>>>>> It belongs to system-tools-backends (version 2.10.1), see above.
>>>>>>>
>>>>>>> Yes, I could write more policy, but I would first prefer to get this
>>>>>>> committed, otherwise it's pointless and too much stuff at the same time
>>>>>>> can be confusing and in turn this could lead to mistakes.
>>>>>>
>>>>>> Yes but if you write policy for this then we may not need to allow dbus
>>>>>> access to execute generic bin files.
>>>>>>
>>>>>> Although eventually we will probably have to allow it that anyways
>>>>>
>>>>> Yes. The DBus module needs { read open execute } permissions for
>>>>> executing python in the system_dbusd_t domain. And that is bin_t:file,
>>>>> so there is little it can be done to get around this issue.
> 
> What do you say about the latest issue mentioned above ? Apparently
> execute_no_trans in not enough for dbus to execute python. It is also
> requiring the execute permission. So I thought domain transition could
> help.

i do not think dbusd_system_t needs access to either execute bin_t files
or shell_exec_t files. I think that issue may or may not be caused when
you ran policy kit or system_tools in the dbusd_system_t domain.

> But then the corecmd_bin_domtrans() interface mentions that "this is not
> suggested". What does that comment mean exactly ? Isn't that still
> better than allowing system_dbusd_t bin_t:file execute ?
> 
> Regards,
> 
> Guido
> 

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

iEYEARECAAYFAk1B2KoACgkQMlxVo39jgT9siQCgsErYCcpB3aRwNxytZWBm85bd
0tUAnRl25OMqOu84uAPW2jzOKANh/THQ
=OxjA
-----END PGP SIGNATURE-----