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

Thu Jan 27 14:36:09 CST 2011

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.

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