From: domg472@gmail.com (Dominick Grift) Date: Wed, 26 Jan 2011 18:49:15 +0100 Subject: [refpolicy] [PATCH/RFC 8/19]: patch set to update the git reference policy In-Reply-To: <1296062881.3028.18.camel@tesla.lan> 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> Message-ID: <4D405E9B.8050107@gmail.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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) When you make dbus transition to policykit_t by calling the dbus_system_domain(), then that may affect other changes you made to the dbus module. for example: +allow system_dbusd_t self:capability { dac_override setgid setpcap setuid sys_ptrace }; This might no longer be needed. Maybe policykit needed it? same goes for the other changes (system-tools-backends) So i would test the dbus_system_domain() and remove all added policy from bdus module and then see if you can reproduce any of it, since the whole scenario changed by specifying the domain transition. >>>>>>> >>>>>>> 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. > >>>>> and this is the log: >>>>> >>>>> type=AVC msg=audit(1294879948.810:42): avc: denied { execute } for >>>>> pid=2966 comm="dbus-daemon-lau" name="SystemToolsBackends.pl" dev=dm-1 >>>>> ino=442334 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 >>>>> tcontext=system_u:object_r:usr_t:s0 tclass=file >>>>> >>>>> for the moment I have just written a comment in the TE file. Otherwise, >>>>> we should relabel the perl script. What do you suggest ? >>>>> >>>>>>> +files_read_var_lib_files(system_dbusd_t) >>>>>>> +files_var_log_append(system_dbusd_t) >>>>>> >>>>>> Which log is it appending to? >>>>> >>>>> Can't find the logs. Again, I can remove and test again, so we might get >>>>> a better insight. Will let you know shortly. >>> >>> In any case, I had re-invented the wheel with those files_*_var_log_* >>> interfaces. They are already available in the logging module, so all of >>> them have now disappeared. >> >> Still question remains, which log files is it appending? > > That is not showing up anymore since I had removed it. So at the moment > I can't tell you anything more. > > There is something new in another module (devicekit): > fs_getattr_xattr_fs permissions needed both in devicekit_{disk,power}_t. > That was [9/19] for reference and I also wrote a short note in that > thread. > > So, we have almost finished tidying up things. > > What's next ? > > Regards, > > Guido > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1AXpsACgkQMlxVo39jgT9psQCgop2D2UC+nUV1RgB7/JQuUxDU 9IEAnjYk8LqbfHvtQ1eaK3w1PWArBSym =zemB -----END PGP SIGNATURE-----