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

[domg472@gmail.com (Dominick Grift)]

-----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 @@
>  
>  ########################################
>  ## <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).
> 

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-----