From: domg472@gmail.com (Dominick Grift) Date: Fri, 28 Jan 2011 18:01:43 +0100 Subject: [refpolicy] [PATCH/RFC 8/19]: patch set to update the git reference policy In-Reply-To: <1296264740.3113.16.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> Message-ID: <4D42F677.2060805@gmail.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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). > 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? > > 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? 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 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). > 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. 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/ iEYEARECAAYFAk1C9ncACgkQMlxVo39jgT9FugCfa3mBc6jntF5HkO+YRWJc+LdM nbIAn2kgvoBD4ncHZiAI0LMiAyAUv7mu =TSm/ -----END PGP SIGNATURE-----