[refpolicy] [PATCH/RFC 8/19]: patch set to update the git reference policy

[guido@trentalancia.com (Guido Trentalancia)]

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 @@
> >  
> >  ########################################
> >  ## <summary>
> > +##      Send a dbus message to
> > +##      policykit.
> > +## </summary>
> > +## <param name="domain">
> > +##      <summary>
> > +##      Domain allowed access.
> > +##      </summary>
> > +## </param>
> > +#
> > +interface(`policykit_dbus_send',`
> > +	gen_require(`
> > +		type policykit_t;
> > +		class dbus send_msg;
> > +	')
> > +
> > +	allow $1 policykit_t:dbus send_msg;
> > +')
> > +
> > +########################################
> > +## <summary>
> >  ##	Send and receive messages from
> >  ##	policykit over dbus.
> >  ## </summary>
> > --- 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