From: guido@trentalancia.com (Guido Trentalancia) Date: Fri, 28 Jan 2011 19:38:37 +0100 Subject: [refpolicy] [PATCH/RFC 8/19]: patch set to update the git reference policy In-Reply-To: <4D42F677.2060805@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> <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> Message-ID: <1296239917.3070.14.camel@tesla.lan> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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). > > > 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. > > 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) ? > 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. 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