From: guido@trentalancia.com (Guido Trentalancia) Date: Thu, 27 Jan 2011 01:37:12 +0100 Subject: [refpolicy] [PATCH/RFC 8/19]: patch set to update the git reference policy In-Reply-To: <4D405B81.9050608@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> Message-ID: <1296088632.15344.34.camel@tesla.lan> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com Hi Dominick ! 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. > > > >>>>> 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. Ok, that's fine. Wise idea ! If there was some rush then that was just motivated by the fact that if somebody downloads the latest reference policy and tries to install it on a system similar to the one that I run (just a recent generic installation using an X server, DBus, PolicyKit and not much else), then that would probably be unusable. So, I just thought: better commiting something immediately and then eventually fix minor issues that we might find on the way. But yes, it's always good to do some more testing, take some more time to improve style, uniformity and other good things like that. Not that I had relieved myself from doing that even if something was going to get committed earlier... I'd be very happy to hear from Christopher too, but perhaps he's been busy these days... And of course from Justin and the others. Anyway, I'll let you know about the dbus_system_domain rule. Thanks again for pointing that out. By the way, this is the case of uni-directional messaging with DBus (signal): http://dbus.freedesktop.org/doc/dbus-tutorial.html#signalprocedure Because the elementary data-flow is uni-directional, then messaging is best modelled accordingly. And apart from the above consideration, think of the case of two modules A and B (with their respective SELinux policy modules A.pp and B.pp) that need to send and receive messages (between each other). If all permissions (for A to send_msg and for B to send_msg) are granted in only one of the two modules (say for example A), then what would happen to the other module (B in the example) if the first one (A in the example) is removed ? It would happen that the second module (B in the example) loses its ability to send messages (not just to A, which does not exist anymore, but also to other entities) ? The right to send messages is something which should be granted individually to each entity, similarly to the right to vote in an assembly, don't you agree ? Best regards, Guido