From: domg472@gmail.com (Dominick Grift) Date: Fri, 28 Jan 2011 19:47:56 +0100 Subject: [refpolicy] [PATCH/RFC 8/19]: patch set to update the git reference policy In-Reply-To: <1296239917.3070.14.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> <4D405B81.9050608@gmail.com> <1296088632.15344.34.camel@tesla.lan> <4D4137E9.9050805@gmail.com> <1296160570.12677.7.camel@tesla.lan> <4D41D8AA.2020707@gmail.com> <1296264740.3113.16.camel@tesla.lan> <4D42F677.2060805@gmail.com> <1296239917.3070.14.camel@tesla.lan> Message-ID: <4D430F5C.4090700@gmail.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/28/2011 07:38 PM, Guido Trentalancia wrote: > On Fri, 28/01/2011 at 18.01 +0100, Dominick Grift wrote: >> On 01/29/2011 02:32 AM, Guido Trentalancia wrote: >>> Hi Dominick ! >>> >>> Thanks so much for getting again back to me with your comments and much >>> valuable suggestions ! >>> >>> On Thu, 27/01/2011 at 21.42 +0100, Dominick Grift 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. >>>> >>>> i do not think dbusd_system_t needs access to either execute bin_t files >>>> or shell_exec_t files. I think that issue may or may not be caused when >>>> you ran policy kit or system_tools in the dbusd_system_t domain. >>> >>> No, DBus doesn't need to execute bin_t and shell_exec_t files, but this >>> is required by system-tools-backed (see this piece of audit): >>> >>> type=AVC msg=audit(1296262894.482:20): avc: denied { execute } for >>> pid=2933 comm="SystemToolsBack" name="bash" dev=dm-1 ino=208876 >>> scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 >>> tcontext=system_u:object_r:shell_exec_t:s0 tclass=file >>> type=SYSCALL msg=audit(1296262894.482:20): arch=40000003 syscall=11 >>> success=no exit=-13 a0=b772fded a1=bfae4d9c a2=9d50d38 a3=10 items=0 >>> ppid=2924 pid=2933 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 >>> egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="SystemToolsBack" >>> exe="/usr/bin/perl" subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 >>> key=(null) >>> type=AVC msg=audit(1296262894.494:21): avc: denied { execute } for >>> pid=2934 comm="SystemToolsBack" name="bash" dev=dm-1 ino=208876 >>> scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 >>> tcontext=system_u:object_r:shell_exec_t:s0 tclass=file >>> type=SYSCALL msg=audit(1296262894.494:21): arch=40000003 syscall=11 >>> success=no exit=-13 a0=b7709ded a1=bf912e8c a2=88fcd38 a3=10 items=0 >>> ppid=2925 pid=2934 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 >>> egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="SystemToolsBack" >>> exe="/usr/bin/perl" subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 >>> key=(null) >>> >>> We had agreed that the SystemTooBackend.pl script had to be labelled >>> bin_t, so that's what happens next. >>> >>> Otherwise, since a specific module for system-tools-backends is not >>> present in refpolicy and since it is auxiliary, then the best thing to >>> do is to probably drop all of this from the changes. >>> >> >> We need to figure out what exactly runs this file "SystemToolsBack" and >> SystemTooBackend.pl. If it is really dbus like the avc denial above >> suggest then we should confine it (make a dbus_system_domain). any news on this? >>> Executing polkitd with a domain transition led to the need of writing >>> changes for the policykit module. This is the best solution. Briefly, >>> here is what changed there: >>> >>> --- refpolicy-git-24012011/policy/modules/services/policykit.te 2011-01-08 19:07:21.281747514 +0100 >>> +++ refpolicy-git-24012011-new/policy/modules/services/policykit.te 2011-01-29 02:06:11.984160210 +0100 >>> @@ -35,8 +35,8 @@ files_pid_file(policykit_var_run_t) >>> # policykit local policy >>> # >>> >>> -allow policykit_t self:capability { setgid setuid }; >>> -allow policykit_t self:process getattr; >>> +allow policykit_t self:capability { setgid setuid sys_ptrace }; >>> +allow policykit_t self:process { getattr getsched signal }; >>> allow policykit_t self:fifo_file rw_file_perms; >>> allow policykit_t self:unix_dgram_socket create_socket_perms; >>> allow policykit_t self:unix_stream_socket create_stream_socket_perms; >>> @@ -57,9 +57,11 @@ manage_files_pattern(policykit_t, policy >>> files_pid_filetrans(policykit_t, policykit_var_run_t, { file dir }) >>> >>> kernel_read_kernel_sysctls(policykit_t) >>> +kernel_read_system_state(policykit_t) >>> >>> files_read_etc_files(policykit_t) >>> files_read_usr_files(policykit_t) >>> +files_read_var_lib_files(policykit_t) >> >> What is this file exaclty? > > Stuff in /var/lib/polkit-1 is all labelled generic var_lib_t. > so that is obviously mislabeled. and this this should not be allowed. /var/lib/polkit-1(/.*)? gen_context(system_u:object_r:policykit_var_lib_t,s0) >>> auth_use_nsswitch(policykit_t) >>> >>> @@ -69,6 +71,23 @@ miscfiles_read_localization(policykit_t) >>> >>> userdom_read_all_users_state(policykit_t) >>> >>> +optional_policy(` >>> + consolekit_read_pid_files(policykit_t) >>> +') >>> + >>> +optional_policy(` >>> + dbus_system_domain(policykit_t, policykit_exec_t) >>> +') >>> + >>> +optional_policy(` >>> + gnome_read_config(policykit_t) >> >> Which file/dirs is it reading exactly? > > Just HOME_DIR/.config/user-dirs.* so far. I don't think it won't ever > need to read anything else. > >> This (~/.config) is not really gnome owned. It is XDG freedesktop base >> directory standard. Also used by KDE etc (not gnome specific) >> >> Either leave that labelled user_home_t or implement it in a more neutral >> way. (i added a new xdg module which can be used even if gnome /or gnome >> module is not installed (example kde or whatever other gui) >> >>> +') >>> + >>> +optional_policy(` >>> + xserver_read_xdm_files(policykit_t) >> >> it probably also need xserver_append_xdm_home_files() altough that might >> currently be dontaudited in refpolicy >> >>> + xserver_xdm_dbus_send(policykit_t) >> >> You will probably want to nest this optional policy block in the >> optional_policy block that has the dbus_system_domain call. >> >> example: >> >> optional_policy(` >> dbus_system_domain(policykit_t, policykit_exec_t) >> >> optional_policy(` >> xserver_read_xdm_files(policykit_t) >> xserver_xdm_dbus_send(policykit_t) >> ') >> ') >> >> Or somthing like this > > Yes, will look into that possibility. Are you sure that PolicyKit cannot > be used with X independently of DBus (apart from the messaging thing) ? you could also try this: optional_policy(` xserver_read_xdm_files(policykit_t) optional_policy(` xserver_xdm_dbus_send(policykit_t) ') ') Athough in these simple cases nesting optionals is often not really needed. Yet its good to do it right anyway. >> Because if dbus_system_domain is unavailable (e.g. if dbus is not >> installed or dbus module is disabled), then xserver_xdm_dbus_send wont >> be working/or available either. >> >>> +') >>> + >>> ######################################## >>> # >>> # polkit_auth local policy >>> --- refpolicy-git-24012011/policy/modules/services/policykit.if 2011-01-08 19:07:21.281747514 +0100 >>> +++ refpolicy-git-24012011-new/policy/modules/services/policykit.if 2011-01-28 09:08:23.971309454 +0100 >>> @@ -2,6 +2,26 @@ >>> >>> ######################################## >>> ## >>> +## Send a dbus message to >>> +## policykit. >>> +## >>> +## >>> +## >>> +## Domain allowed access. >>> +## >>> +## >>> +# >>> +interface(`policykit_dbus_send',` >>> + gen_require(` >>> + type policykit_t; >>> + class dbus send_msg; >>> + ') >>> + >>> + allow $1 policykit_t:dbus send_msg; >>> +') >>> + >>> +######################################## >>> +## >>> ## Send and receive messages from >>> ## policykit over dbus. >>> ## >>> --- refpolicy-git-24012011/policy/modules/apps/gnome.fc 2011-01-08 19:07:21.179731404 +0100 >>> +++ refpolicy-git-24012011-new/policy/modules/apps/gnome.fc 2011-01-28 10:00:28.356571615 +0100 >>> @@ -1,4 +1,4 @@ >>> -HOME_DIR/\.config/gtk-.* gen_context(system_u:object_r:gnome_home_t,s0) >>> +HOME_DIR/\.config(/.*)? gen_context(system_u:object_r:gnome_home_t,s0) >> >> ~/.config is not specific to gnome >> >>> HOME_DIR/\.gconf(d)?(/.*)? gen_context(system_u:object_r:gconf_home_t,s0) >>> HOME_DIR/\.gnome2(/.*)? gen_context(system_u:object_r:gnome_home_t,s0) >>> >>> With the addition of policykit_dbus_send(xdm_t) as optional policy in >>> xserver.te (because I am splitting the send_msg permission). >>> >>> What do you think ? For example, relabelling of the whole >>> HOME_DIR/.config directory to something other than generic home_t sounds >>> quite nice to me, as home_t might include personal data of the user and >>> configuration should not mixed up with that. Now to the best of my >>> knowledge that .config directory is only used by gnome (and mainly >>> xdg-user-dirs from freedesktop.org to be more precise). > > There is a package named xdg-user-dirs-gtk which is in gnome.org. The > rest (xdg-user-dirs and utils) is from freedesktop.org. > > Yes initially my idea was to create something like xdg_config_t. That > can still be done, but in gnome.fc as for the first set of patches there > is not much time to create extra modules. Just leave it user_home_t for now. Because we need consensus about this first. > Leaving the whole HOME_DIR/.config as generic home_t doesn't sound quite > right to me. One could just relabel what is needed by xdg (user-dirs.*, > see above) but then that would still be suboptimal because there is > other stuff (from gnome-session, ibus, gnome-disk-utility and so on) > which clearly is not generic home content. > > So shall I go for relabelling the parent dir as xdg_config_t, perhaps > leave gtk subdir as gnome_home_t and just default anything else to > xdg_config_t ? > >> i implemented it as a seperate module called xdg. Not just for ~/.config >> (config_home_t), but also ~/.cache (cache_home_t) and ~/.local/share >> (data_home_t) as per xdg freedesktop base directory specification. >> >> We need consensus about how to best implement support for XDG. But i >> personally do not believe it is a good idea to tie this to gnome. >> Because its not gnome specific. > > Yes, that's fine to me. I am even more happy actually. Does xdm_config_t > sound reasonable to you (see above) ? > >> see my xdg module here: >> >> http://fedorapeople.org/gitweb?p=domg472/public_git/refpolicy.git;a=tree;f=policy/modules/apps;h=3260ad02daa84f2823b3f063066bd9b02c239498;hb=HEAD >> >>> By the way, I couldn't watch your blog presentations because they >>> require high-bandwidth from youtube and at the moment I am connected >>> with just a UMTS mobile phone. Why don't you write up a text document as >>> PDF or something else that can also be searched and used as a >>> reference ? >> >> I am not a good writer. I can be a "technical editor" but i am not a >> writer. I need someone with documentation experience to collaborate with me. > > Regards, > > Guido > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1DD1wACgkQMlxVo39jgT8mDACgqWCsM1nHzzP4pYmfYNlNQVnO WqwAnjI30VhIhnlifXfN3wK4EW2jaLy/ =uLfl -----END PGP SIGNATURE-----