From: guido@trentalancia.com (Guido Trentalancia) Date: Thu, 27 Jan 2011 21:36:09 +0100 Subject: [refpolicy] [PATCH/RFC 8/19]: patch set to update the git reference policy In-Reply-To: <4D4137E9.9050805@gmail.com> References: <1295829851.3862.67.camel@tesla.lan> <4D3D8703.8040308@gmail.com> <1295982348.11770.16.camel@tesla.lan> <4D3F2245.9090606@gmail.com> <1296002515.16768.18.camel@tesla.lan> <4D3FD8B5.9030306@gmail.com> <1296062881.3028.18.camel@tesla.lan> <4D405B81.9050608@gmail.com> <1296088632.15344.34.camel@tesla.lan> <4D4137E9.9050805@gmail.com> Message-ID: <1296160570.12677.7.camel@tesla.lan> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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