From: domg472@gmail.com (Dominick Grift) Date: Wed, 26 Jan 2011 18:36:01 +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: <4D405B81.9050608@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) >>>>>>> >>>>>>> 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 ? That is up to you. I would probably do some more testing and not rush to sending patches out just yet. Double check the stuff you added. Create nice clear explained small and to the point patches. Make sure it all works. Make sure its complete , uniform, conforms to style rules, is typo free etc. > Regards, > > Guido > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1AW4AACgkQMlxVo39jgT8PpACgnxFIOTH+BsRR7GN2+iQZ6pkh x7MAoJdSyMnQ46MbjMymzdUUKudEoKog =6B5O -----END PGP SIGNATURE-----