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

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

[Guido Trentalancia]

--- 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)
+files_read_default_files(system_dbusd_t)
 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)
+files_exec_usr_files(system_dbusd_t)
+files_read_var_lib_files(system_dbusd_t)
+files_var_log_append(system_dbusd_t)
 
 init_use_fds(system_dbusd_t)
 init_use_script_ptys(system_dbusd_t)
@@ -141,6 +148,7 @@ optional_policy(`
 ')
 
 optional_policy(`
+	consolekit_read_pid_files(system_dbusd_t)
 	consolekit_dbus_send(system_dbusd_t)
 ')
 

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

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

> +files_read_default_files(system_dbusd_t)

there should not be any default_t type files. Thus this shouldnt be allowed

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

> +files_exec_usr_files(system_dbusd_t)

Which usr_t files is it executing?

> +files_read_var_lib_files(system_dbusd_t)
> +files_var_log_append(system_dbusd_t)

Which log is it appending to?
>  
>  init_use_fds(system_dbusd_t)
>  init_use_script_ptys(system_dbusd_t)
> @@ -141,6 +148,7 @@ optional_policy(`
>  ')
>  
>  optional_policy(`
> +	consolekit_read_pid_files(system_dbusd_t)
>  	consolekit_dbus_send(system_dbusd_t)
>  ')
>  
> 
> 
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk09hwMACgkQMlxVo39jgT86yACePzJOPj70ApDLX5Jta9xnUxdC
ntkAoLT/WPghTDXhXd6E02Fy3lupbNdI
=4wrb
-----END PGP SIGNATURE-----

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

[Guido Trentalancia]

Hello Dominick !

Just a quick comment on the default_t label/permissions, as I still need
to check the rest of this [8/19] comment...

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
> 
> > +files_read_default_files(system_dbusd_t)
> 
> there should not be any default_t type files. Thus this shouldnt be allowed

The point here is that with the reference policy root's home directory
doesn't get its own label but rather fall back to default_t. This is why
I had created those permissions, although I wasn't completely sure about
it because of course it doesn't appear anywhere else.

On Fedora, it's different as they have patched that as follows (taken
from F14 patch in this example):

diff --exclude-from=exclude -N -u -r
nsaserefpolicy/policy/modules/system/userdomain.fc
serefpolicy-3.9.7/policy/modules/system/userdomain.fc
--- nsaserefpolicy/policy/modules/system/userdomain.fc  2010-10-12
22:42:50.000000000 +0200
+++ serefpolicy-3.9.7/policy/modules/system/userdomain.fc
2010-11-05 14:02:26.959899962 +0100
@@ -1,4 +1,17 @@
 HOME_DIR       -d
gen_context(system_u:object_r:user_home_dir_t,s0-mls_systemhigh)
+HOME_DIR       -l
gen_context(system_u:object_r:user_home_dir_t,s0-mls_systemhigh)
 HOME_DIR/.+            gen_context(system_u:object_r:user_home_t,s0)
-
 /tmp/gconfd-USER -d    gen_context(system_u:object_r:user_tmp_t,s0)
+/root(/.*)?            gen_context(system_u:object_r:admin_home_t,s0)
+/root/\.cert(/.*)?     gen_context(system_u:object_r:home_cert_t,s0)
+/root/\.debug(/.*)?    <<none>>
+/dev/shm/pulse-shm.*   gen_context(system_u:object_r:user_tmpfs_t,s0)
+/dev/shm/mono.*
gen_context(system_u:object_r:user_tmpfs_t,s0)
+HOME_DIR/bin(/.*)?     gen_context(system_u:object_r:home_bin_t,s0)
+HOME_DIR/local/bin(/.*)?
gen_context(system_u:object_r:home_bin_t,s0)
+HOME_DIR/Audio(/.*)?    gen_context(system_u:object_r:audio_home_t,s0)
+HOME_DIR/Music(/.*)?    gen_context(system_u:object_r:audio_home_t,s0)
+HOME_DIR/\.cert(/.*)?  gen_context(system_u:object_r:home_cert_t,s0)
+HOME_DIR/\.pki(/.*)?
gen_context(system_u:object_r:home_cert_t,s0)
+HOME_DIR/\.gvfs(/.*)?  <<none>>
+HOME_DIR/\.debug(/.*)? <<none>>

On Debian, it's also being labelled user_home_t. But when I have
installed the plain reference policy, it didn't label any home directory
at all: the type *_home_t does not appear at all in the "standard" file
contexts. So I thought that was the intended behaviour for the reference
policy. I had just followed the INSTALL document...

What do you say ?

Regards,

Guido

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

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/25/2011 01:03 AM, Guido Trentalancia wrote:
> Hello Dominick !
> 
> Just a quick comment on the default_t label/permissions, as I still need
> to check the rest of this [8/19] comment...
> 
> 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
>>
>>> +files_read_default_files(system_dbusd_t)
>>
>> there should not be any default_t type files. Thus this shouldnt be allowed
> 
> The point here is that with the reference policy root's home directory
> doesn't get its own label but rather fall back to default_t. This is why
> I had created those permissions, although I wasn't completely sure about
> it because of course it doesn't appear anywhere else.
> 

What distro are you testing your policy on? this should not be
happening. On non-redhat distros /root should be user_home_dir_t.

It could be that youre using a redhat influence libsemanage. Or maybe
that you need to edit semanage,conf

Here is how i solve this issue:

- - create a "super user"

useradd $SUPERUSER
passwd $SUPERUSER
semanage login -a -s staff_u -r s0-s0:c0.c1023 $SUPERUSER

- - fix the contexts for /root:

semanage fcontext -a -e /home/$SUPERUSER /root
restorecon -R -v /root

- - use sudo to get to root shell:

echo "$SUPERUSER ALL=(ALL) ROLE=sysadm_r TYPE=sysadm_t ALL" >
/etc/sudoers.d/$SUPERUSER
chmod 0440 /etc/sudoers.d/$SUPERUSER

Again default_t types should not be there in a system. It means your
system has locations unknown to selinux.

> On Fedora, it's different as they have patched that as follows (taken
> from F14 patch in this example):
> 
> diff --exclude-from=exclude -N -u -r
> nsaserefpolicy/policy/modules/system/userdomain.fc
> serefpolicy-3.9.7/policy/modules/system/userdomain.fc
> --- nsaserefpolicy/policy/modules/system/userdomain.fc  2010-10-12
> 22:42:50.000000000 +0200
> +++ serefpolicy-3.9.7/policy/modules/system/userdomain.fc
> 2010-11-05 14:02:26.959899962 +0100
> @@ -1,4 +1,17 @@
>  HOME_DIR       -d
> gen_context(system_u:object_r:user_home_dir_t,s0-mls_systemhigh)
> +HOME_DIR       -l
> gen_context(system_u:object_r:user_home_dir_t,s0-mls_systemhigh)
>  HOME_DIR/.+            gen_context(system_u:object_r:user_home_t,s0)
> -
>  /tmp/gconfd-USER -d    gen_context(system_u:object_r:user_tmp_t,s0)
> +/root(/.*)?            gen_context(system_u:object_r:admin_home_t,s0)
> +/root/\.cert(/.*)?     gen_context(system_u:object_r:home_cert_t,s0)
> +/root/\.debug(/.*)?    <<none>>
> +/dev/shm/pulse-shm.*   gen_context(system_u:object_r:user_tmpfs_t,s0)
> +/dev/shm/mono.*
> gen_context(system_u:object_r:user_tmpfs_t,s0)
> +HOME_DIR/bin(/.*)?     gen_context(system_u:object_r:home_bin_t,s0)
> +HOME_DIR/local/bin(/.*)?
> gen_context(system_u:object_r:home_bin_t,s0)
> +HOME_DIR/Audio(/.*)?    gen_context(system_u:object_r:audio_home_t,s0)
> +HOME_DIR/Music(/.*)?    gen_context(system_u:object_r:audio_home_t,s0)
> +HOME_DIR/\.cert(/.*)?  gen_context(system_u:object_r:home_cert_t,s0)
> +HOME_DIR/\.pki(/.*)?
> gen_context(system_u:object_r:home_cert_t,s0)
> +HOME_DIR/\.gvfs(/.*)?  <<none>>
> +HOME_DIR/\.debug(/.*)? <<none>>
> 
> On Debian, it's also being labelled user_home_t. But when I have
> installed the plain reference policy, it didn't label any home directory
> at all: the type *_home_t does not appear at all in the "standard" file
> contexts. So I thought that was the intended behaviour for the reference
> policy. I had just followed the INSTALL document...
> 
> What do you say ?
> 
> Regards,
> 
> Guido
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk0+l84ACgkQMlxVo39jgT/MhQCeO6YstSTYVmSrXkKVIOnUiYPJ
NmkAoIdDuchef7qAju54fKsTswD1LIg0
=9ymO
-----END PGP SIGNATURE-----

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

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/25/2011 10:28 AM, Dominick Grift wrote:
> On 01/25/2011 01:03 AM, Guido Trentalancia wrote:
>> Hello Dominick !
> 
>> Just a quick comment on the default_t label/permissions, as I still need
>> to check the rest of this [8/19] comment...
> 
>> 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
>>>
>>>> +files_read_default_files(system_dbusd_t)
>>>
>>> there should not be any default_t type files. Thus this shouldnt be allowed
> 
>> The point here is that with the reference policy root's home directory
>> doesn't get its own label but rather fall back to default_t. This is why
>> I had created those permissions, although I wasn't completely sure about
>> it because of course it doesn't appear anywhere else.
> 
> 
> What distro are you testing your policy on? this should not be
> happening. On non-redhat distros /root should be user_home_dir_t.
> 
> It could be that youre using a redhat influence libsemanage. Or maybe
> that you need to edit semanage,conf
> 
> Here is how i solve this issue:
> 
> - create a "super user"
> 
> useradd $SUPERUSER
> passwd $SUPERUSER
> semanage login -a -s staff_u -r s0-s0:c0.c1023 $SUPERUSER
> 
> - fix the contexts for /root:
> 
> semanage fcontext -a -e /home/$SUPERUSER /root
> restorecon -R -v /root
> 
> - use sudo to get to root shell:
> 
> echo "$SUPERUSER ALL=(ALL) ROLE=sysadm_r TYPE=sysadm_t ALL" >
> /etc/sudoers.d/$SUPERUSER
> chmod 0440 /etc/sudoers.d/$SUPERUSER
> 
> Again default_t types should not be there in a system. It means your
> system has locations unknown to selinux.
> 
>> On Fedora, it's different as they have patched that as follows (taken
>> from F14 patch in this example):
> 
>> diff --exclude-from=exclude -N -u -r
>> nsaserefpolicy/policy/modules/system/userdomain.fc
>> serefpolicy-3.9.7/policy/modules/system/userdomain.fc
>> --- nsaserefpolicy/policy/modules/system/userdomain.fc  2010-10-12
>> 22:42:50.000000000 +0200
>> +++ serefpolicy-3.9.7/policy/modules/system/userdomain.fc
>> 2010-11-05 14:02:26.959899962 +0100
>> @@ -1,4 +1,17 @@
>>  HOME_DIR       -d
>> gen_context(system_u:object_r:user_home_dir_t,s0-mls_systemhigh)
>> +HOME_DIR       -l
>> gen_context(system_u:object_r:user_home_dir_t,s0-mls_systemhigh)
>>  HOME_DIR/.+            gen_context(system_u:object_r:user_home_t,s0)
>> -
>>  /tmp/gconfd-USER -d    gen_context(system_u:object_r:user_tmp_t,s0)
>> +/root(/.*)?            gen_context(system_u:object_r:admin_home_t,s0)
>> +/root/\.cert(/.*)?     gen_context(system_u:object_r:home_cert_t,s0)
>> +/root/\.debug(/.*)?    <<none>>
>> +/dev/shm/pulse-shm.*   gen_context(system_u:object_r:user_tmpfs_t,s0)
>> +/dev/shm/mono.*
>> gen_context(system_u:object_r:user_tmpfs_t,s0)
>> +HOME_DIR/bin(/.*)?     gen_context(system_u:object_r:home_bin_t,s0)
>> +HOME_DIR/local/bin(/.*)?
>> gen_context(system_u:object_r:home_bin_t,s0)
>> +HOME_DIR/Audio(/.*)?    gen_context(system_u:object_r:audio_home_t,s0)
>> +HOME_DIR/Music(/.*)?    gen_context(system_u:object_r:audio_home_t,s0)
>> +HOME_DIR/\.cert(/.*)?  gen_context(system_u:object_r:home_cert_t,s0)
>> +HOME_DIR/\.pki(/.*)?
>> gen_context(system_u:object_r:home_cert_t,s0)
>> +HOME_DIR/\.gvfs(/.*)?  <<none>>
>> +HOME_DIR/\.debug(/.*)? <<none>>
> 
>> On Debian, it's also being labelled user_home_t. But when I have
>> installed the plain reference policy, it didn't label any home directory
>> at all: the type *_home_t does not appear at all in the "standard" file
>> contexts. So I thought that was the intended behaviour for the reference
>> policy. I had just followed the INSTALL document...
> 
>> What do you say ?

It is not intended behaviour but redhat uses another approach to /root
labelling. It may be that because redhat contributes also alot to
selinux toolchain, that some redhat specific changes to toolchain
slipped through the cracks, and ended up in upstream toolchain.

Or it may the that it didnt slip through the cracks but was adopted
intentionally and you need to edit some configuration file like
semanage.conf.

Either way: /root should not be default_t. So i guess its either a bug
or misconfiguration somewhere (libsemanage?)

>> Regards,
> 
>> Guido
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk0+vJUACgkQMlxVo39jgT966wCfaCsqaojdL4Q8GHQk+TuxDbuk
SzUAn288i4pe6FNVF/WTW0fSDKTgRaQW
=SLPK
-----END PGP SIGNATURE-----

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

[Guido Trentalancia]

On Tue, 25/01/2011 at 13.05 +0100, Dominick Grift wrote:
> On 01/25/2011 10:28 AM, Dominick Grift wrote:
> > On 01/25/2011 01:03 AM, Guido Trentalancia wrote:
> >> Hello Dominick !
> > 
> >> Just a quick comment on the default_t label/permissions, as I still need
> >> to check the rest of this [8/19] comment...
> > 
> >> 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
> >>>
> >>>> +files_read_default_files(system_dbusd_t)
> >>>
> >>> there should not be any default_t type files. Thus this shouldnt be allowed
> > 
> >> The point here is that with the reference policy root's home directory
> >> doesn't get its own label but rather fall back to default_t. This is why
> >> I had created those permissions, although I wasn't completely sure about
> >> it because of course it doesn't appear anywhere else.
> > 
> > 
> > What distro are you testing your policy on? this should not be
> > happening. On non-redhat distros /root should be user_home_dir_t.

It's not a distribution. It's latest Linux components built and
installed by myself.
 
> > It could be that youre using a redhat influence libsemanage. Or maybe
> > that you need to edit semanage,conf

Yes, the latter. Misconfiguration of libsemanage. Should be fixed now. I
will remove all occurrences of default_t permissions.

> > Here is how i solve this issue:
> > 
> > - create a "super user"
> > 
> > useradd $SUPERUSER
> > passwd $SUPERUSER
> > semanage login -a -s staff_u -r s0-s0:c0.c1023 $SUPERUSER
> > 
> > - fix the contexts for /root:
> > 
> > semanage fcontext -a -e /home/$SUPERUSER /root
> > restorecon -R -v /root
> > 
> > - use sudo to get to root shell:
> > 
> > echo "$SUPERUSER ALL=(ALL) ROLE=sysadm_r TYPE=sysadm_t ALL" >
> > /etc/sudoers.d/$SUPERUSER
> > chmod 0440 /etc/sudoers.d/$SUPERUSER

Just restorecon -R /root did the job.

Regards,

Guido

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

[Guido Trentalancia]

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

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

and this is the log:

type=AVC msg=audit(1294879948.810:42): avc:  denied  { execute } for
pid=2966 comm="dbus-daemon-lau" name="SystemToolsBackends.pl" dev=dm-1
ino=442334 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:usr_t:s0 tclass=file

for the moment I have just written a comment in the TE file. Otherwise,
we should relabel the perl script. What do you suggest ?

> > +files_read_var_lib_files(system_dbusd_t)
> > +files_var_log_append(system_dbusd_t)
> 
> Which log is it appending to?

Can't find the logs. Again, I can remove and test again, so we might get
a better insight. Will let you know shortly.
  
> >  init_use_fds(system_dbusd_t)
> >  init_use_script_ptys(system_dbusd_t)
> > @@ -141,6 +148,7 @@ optional_policy(`
> >  ')
> >  
> >  optional_policy(`
> > +	consolekit_read_pid_files(system_dbusd_t)
> >  	consolekit_dbus_send(system_dbusd_t)
> >  ')

Regards,

Guido

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

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

This depends on what dbus is doing with policykit

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

> and this is the log:
> 
> type=AVC msg=audit(1294879948.810:42): avc:  denied  { execute } for
> pid=2966 comm="dbus-daemon-lau" name="SystemToolsBackends.pl" dev=dm-1
> ino=442334 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
> tcontext=system_u:object_r:usr_t:s0 tclass=file
> 
> for the moment I have just written a comment in the TE file. Otherwise,
> we should relabel the perl script. What do you suggest ?
> 
>>> +files_read_var_lib_files(system_dbusd_t)
>>> +files_var_log_append(system_dbusd_t)
>>
>> Which log is it appending to?
> 
> Can't find the logs. Again, I can remove and test again, so we might get
> a better insight. Will let you know shortly.
>   
>>>  init_use_fds(system_dbusd_t)
>>>  init_use_script_ptys(system_dbusd_t)
>>> @@ -141,6 +148,7 @@ optional_policy(`
>>>  ')
>>>  
>>>  optional_policy(`
>>> +	consolekit_read_pid_files(system_dbusd_t)
>>>  	consolekit_dbus_send(system_dbusd_t)
>>>  ')
> 
> Regards,
> 
> Guido
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk0/IkUACgkQMlxVo39jgT9oIQCdF6EErCKBCYLjcYRDetjiqeqz
4zoAoKLxifXrpJ/SDGxPotOeeGstD1Uc
=g4hH
-----END PGP SIGNATURE-----

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

[Guido Trentalancia]

Hello Dominick !

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 ?

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

> > and this is the log:
> > 
> > type=AVC msg=audit(1294879948.810:42): avc:  denied  { execute } for
> > pid=2966 comm="dbus-daemon-lau" name="SystemToolsBackends.pl" dev=dm-1
> > ino=442334 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
> > tcontext=system_u:object_r:usr_t:s0 tclass=file
> > 
> > for the moment I have just written a comment in the TE file. Otherwise,
> > we should relabel the perl script. What do you suggest ?
> > 
> >>> +files_read_var_lib_files(system_dbusd_t)
> >>> +files_var_log_append(system_dbusd_t)
> >>
> >> Which log is it appending to?
> > 
> > Can't find the logs. Again, I can remove and test again, so we might get
> > a better insight. Will let you know shortly.

In any case, I had re-invented the wheel with those files_*_var_log_*
interfaces. They are already available in the logging module, so all of
them have now disappeared.

Regards,

Guido

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

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/26/2011 01:41 AM, Guido Trentalancia wrote:
> Hello Dominick !
> 
> 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)

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

> 
>>> and this is the log:
>>>
>>> type=AVC msg=audit(1294879948.810:42): avc:  denied  { execute } for
>>> pid=2966 comm="dbus-daemon-lau" name="SystemToolsBackends.pl" dev=dm-1
>>> ino=442334 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
>>> tcontext=system_u:object_r:usr_t:s0 tclass=file
>>>
>>> for the moment I have just written a comment in the TE file. Otherwise,
>>> we should relabel the perl script. What do you suggest ?
>>>
>>>>> +files_read_var_lib_files(system_dbusd_t)
>>>>> +files_var_log_append(system_dbusd_t)
>>>>
>>>> Which log is it appending to?
>>>
>>> Can't find the logs. Again, I can remove and test again, so we might get
>>> a better insight. Will let you know shortly.
> 
> In any case, I had re-invented the wheel with those files_*_var_log_*
> interfaces. They are already available in the logging module, so all of
> them have now disappeared.

Still question remains, which log files is it appending?

> 
> Regards,
> 
> Guido
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk0/2LUACgkQMlxVo39jgT++9wCglBnNTWhTw+y0FdS80idPF0mk
/r4An1IkIqY0D8PKhqyuKaA00GjGhUT1
=EAy5
-----END PGP SIGNATURE-----

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

[Guido Trentalancia]

Hello Dominick !

On Wed, 26/01/2011 at 09.17 +0100, Dominick Grift wrote:
> On 01/26/2011 01:41 AM, Guido Trentalancia 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.
 
> >>> and this is the log:
> >>>
> >>> type=AVC msg=audit(1294879948.810:42): avc:  denied  { execute } for
> >>> pid=2966 comm="dbus-daemon-lau" name="SystemToolsBackends.pl" dev=dm-1
> >>> ino=442334 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
> >>> tcontext=system_u:object_r:usr_t:s0 tclass=file
> >>>
> >>> for the moment I have just written a comment in the TE file. Otherwise,
> >>> we should relabel the perl script. What do you suggest ?
> >>>
> >>>>> +files_read_var_lib_files(system_dbusd_t)
> >>>>> +files_var_log_append(system_dbusd_t)
> >>>>
> >>>> Which log is it appending to?
> >>>
> >>> Can't find the logs. Again, I can remove and test again, so we might get
> >>> a better insight. Will let you know shortly.
> > 
> > In any case, I had re-invented the wheel with those files_*_var_log_*
> > interfaces. They are already available in the logging module, so all of
> > them have now disappeared.
> 
> Still question remains, which log files is it appending?

That is not showing up anymore since I had removed it. So at the moment
I can't tell you anything more.

There is something new in another module (devicekit):
fs_getattr_xattr_fs permissions needed both in devicekit_{disk,power}_t.
That was [9/19] for reference and I also wrote a short note in that
thread.

So, we have almost finished tidying up things.

What's next ?

Regards,

Guido

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

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/26/2011 06:28 PM, Guido Trentalancia wrote:
> Hello Dominick !
> 
> On Wed, 26/01/2011 at 09.17 +0100, Dominick Grift wrote:
>> On 01/26/2011 01:41 AM, Guido Trentalancia 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.
>  
>>>>> and this is the log:
>>>>>
>>>>> type=AVC msg=audit(1294879948.810:42): avc:  denied  { execute } for
>>>>> pid=2966 comm="dbus-daemon-lau" name="SystemToolsBackends.pl" dev=dm-1
>>>>> ino=442334 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
>>>>> tcontext=system_u:object_r:usr_t:s0 tclass=file
>>>>>
>>>>> for the moment I have just written a comment in the TE file. Otherwise,
>>>>> we should relabel the perl script. What do you suggest ?
>>>>>
>>>>>>> +files_read_var_lib_files(system_dbusd_t)
>>>>>>> +files_var_log_append(system_dbusd_t)
>>>>>>
>>>>>> Which log is it appending to?
>>>>>
>>>>> Can't find the logs. Again, I can remove and test again, so we might get
>>>>> a better insight. Will let you know shortly.
>>>
>>> In any case, I had re-invented the wheel with those files_*_var_log_*
>>> interfaces. They are already available in the logging module, so all of
>>> them have now disappeared.
>>
>> Still question remains, which log files is it appending?
> 
> That is not showing up anymore since I had removed it. So at the moment
> I can't tell you anything more.
> 
> There is something new in another module (devicekit):
> fs_getattr_xattr_fs permissions needed both in devicekit_{disk,power}_t.
> That was [9/19] for reference and I also wrote a short note in that
> thread.
> 
> So, we have almost finished tidying up things.
> 
> What's next ?

That is up to you. I would probably do some more testing and not rush to
sending patches out just yet. Double check the stuff you added. Create
nice clear explained small and to the point patches. Make sure it all
works. Make sure its complete , uniform, conforms to style rules, is
typo free etc.

> Regards,
> 
> Guido
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk1AW4AACgkQMlxVo39jgT8PpACgnxFIOTH+BsRR7GN2+iQZ6pkh
x7MAoJdSyMnQ46MbjMymzdUUKudEoKog
=6B5O
-----END PGP SIGNATURE-----

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

[Guido Trentalancia]

Hi Dominick !

On Wed, 26/01/2011 at 18.36 +0100, Dominick Grift wrote:
> On 01/26/2011 06:28 PM, Guido Trentalancia wrote:
> > Hello Dominick !
> > 
> > On Wed, 26/01/2011 at 09.17 +0100, Dominick Grift wrote:
> >> On 01/26/2011 01:41 AM, Guido Trentalancia 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.
> >  
> >>>>> and this is the log:
> >>>>>
> >>>>> type=AVC msg=audit(1294879948.810:42): avc:  denied  { execute } for
> >>>>> pid=2966 comm="dbus-daemon-lau" name="SystemToolsBackends.pl" dev=dm-1
> >>>>> ino=442334 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
> >>>>> tcontext=system_u:object_r:usr_t:s0 tclass=file
> >>>>>
> >>>>> for the moment I have just written a comment in the TE file. Otherwise,
> >>>>> we should relabel the perl script. What do you suggest ?
> >>>>>
> >>>>>>> +files_read_var_lib_files(system_dbusd_t)
> >>>>>>> +files_var_log_append(system_dbusd_t)
> >>>>>>
> >>>>>> Which log is it appending to?
> >>>>>
> >>>>> Can't find the logs. Again, I can remove and test again, so we might get
> >>>>> a better insight. Will let you know shortly.
> >>>
> >>> In any case, I had re-invented the wheel with those files_*_var_log_*
> >>> interfaces. They are already available in the logging module, so all of
> >>> them have now disappeared.
> >>
> >> Still question remains, which log files is it appending?
> > 
> > That is not showing up anymore since I had removed it. So at the moment
> > I can't tell you anything more.
> > 
> > There is something new in another module (devicekit):
> > fs_getattr_xattr_fs permissions needed both in devicekit_{disk,power}_t.
> > That was [9/19] for reference and I also wrote a short note in that
> > thread.
> > 
> > So, we have almost finished tidying up things.
> > 
> > What's next ?
> 
> That is up to you. I would probably do some more testing and not rush to
> sending patches out just yet. Double check the stuff you added. Create
> nice clear explained small and to the point patches. Make sure it all
> works. Make sure its complete , uniform, conforms to style rules, is
> typo free etc.

Ok, that's fine. Wise idea !

If there was some rush then that was just motivated by the fact that if
somebody downloads the latest reference policy and tries to install it
on a system similar to the one that I run (just a recent generic
installation using an X server, DBus, PolicyKit and not much else), then
that would probably be unusable. So, I just thought: better commiting
something immediately and then eventually fix minor issues that we might
find on the way.

But yes, it's always good to do some more testing, take some more time
to improve style, uniformity and other good things like that. Not that I
had relieved myself from doing that even if something was going to get
committed earlier...

I'd be very happy to hear from Christopher too, but perhaps he's been
busy these days... And of course from Justin and the others.

Anyway, I'll let you know about the dbus_system_domain rule. Thanks
again for pointing that out.

By the way, this is the case of uni-directional messaging with DBus
(signal):

http://dbus.freedesktop.org/doc/dbus-tutorial.html#signalprocedure

Because the elementary data-flow is uni-directional, then messaging is
best modelled accordingly.

And apart from the above consideration, think of the case of two modules
A and B (with their respective SELinux policy modules A.pp and B.pp)
that need to send and receive messages (between each other). If all
permissions (for A to send_msg and for B to send_msg) are granted in
only one of the two modules (say for example A), then what would happen
to the other module (B in the example) if the first one (A in the
example) is removed ?

It would happen that the second module (B in the example) loses its
ability to send messages (not just to A, which does not exist anymore,
but also to other entities) ? The right to send messages is something
which should be granted individually to each entity, similarly to the
right to vote in an assembly, don't you agree ?

Best regards,

Guido

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

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/27/2011 01:37 AM, Guido Trentalancia wrote:
> Hi Dominick !
> 
> On Wed, 26/01/2011 at 18.36 +0100, Dominick Grift wrote:
>> On 01/26/2011 06:28 PM, Guido Trentalancia wrote:
>>> Hello Dominick !
>>>
>>> On Wed, 26/01/2011 at 09.17 +0100, Dominick Grift wrote:
>>>> On 01/26/2011 01:41 AM, Guido Trentalancia 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.
>>>  
>>>>>>> and this is the log:
>>>>>>>
>>>>>>> type=AVC msg=audit(1294879948.810:42): avc:  denied  { execute } for
>>>>>>> pid=2966 comm="dbus-daemon-lau" name="SystemToolsBackends.pl" dev=dm-1
>>>>>>> ino=442334 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
>>>>>>> tcontext=system_u:object_r:usr_t:s0 tclass=file
>>>>>>>
>>>>>>> for the moment I have just written a comment in the TE file. Otherwise,
>>>>>>> we should relabel the perl script. What do you suggest ?
>>>>>>>
>>>>>>>>> +files_read_var_lib_files(system_dbusd_t)
>>>>>>>>> +files_var_log_append(system_dbusd_t)
>>>>>>>>
>>>>>>>> Which log is it appending to?
>>>>>>>
>>>>>>> Can't find the logs. Again, I can remove and test again, so we might get
>>>>>>> a better insight. Will let you know shortly.
>>>>>
>>>>> In any case, I had re-invented the wheel with those files_*_var_log_*
>>>>> interfaces. They are already available in the logging module, so all of
>>>>> them have now disappeared.
>>>>
>>>> Still question remains, which log files is it appending?
>>>
>>> That is not showing up anymore since I had removed it. So at the moment
>>> I can't tell you anything more.
>>>
>>> There is something new in another module (devicekit):
>>> fs_getattr_xattr_fs permissions needed both in devicekit_{disk,power}_t.
>>> That was [9/19] for reference and I also wrote a short note in that
>>> thread.
>>>
>>> So, we have almost finished tidying up things.
>>>
>>> What's next ?
>>
>> That is up to you. I would probably do some more testing and not rush to
>> sending patches out just yet. Double check the stuff you added. Create
>> nice clear explained small and to the point patches. Make sure it all
>> works. Make sure its complete , uniform, conforms to style rules, is
>> typo free etc.
> 
> Ok, that's fine. Wise idea !
> 
> If there was some rush then that was just motivated by the fact that if
> somebody downloads the latest reference policy and tries to install it
> on a system similar to the one that I run (just a recent generic
> installation using an X server, DBus, PolicyKit and not much else), then
> that would probably be unusable. So, I just thought: better commiting
> something immediately and then eventually fix minor issues that we might
> find on the way.
> 
> But yes, it's always good to do some more testing, take some more time
> to improve style, uniformity and other good things like that. Not that I
> had relieved myself from doing that even if something was going to get
> committed earlier...
> 
> I'd be very happy to hear from Christopher too, but perhaps he's been
> busy these days... And of course from Justin and the others.
> 
> Anyway, I'll let you know about the dbus_system_domain rule. Thanks
> again for pointing that out.
> 
> By the way, this is the case of uni-directional messaging with DBus
> (signal):
> 
> http://dbus.freedesktop.org/doc/dbus-tutorial.html#signalprocedure
> 
> Because the elementary data-flow is uni-directional, then messaging is
> best modelled accordingly.
> 
> And apart from the above consideration, think of the case of two modules
> A and B (with their respective SELinux policy modules A.pp and B.pp)
> that need to send and receive messages (between each other). If all
> permissions (for A to send_msg and for B to send_msg) are granted in
> only one of the two modules (say for example A), then what would happen
> to the other module (B in the example) if the first one (A in the
> example) is removed ?
> 
> It would happen that the second module (B in the example) loses its
> ability to send messages (not just to A, which does not exist anymore,
> but also to other entities) ? The right to send messages is something
> which should be granted individually to each entity, similarly to the
> right to vote in an assembly, don't you agree ?
> 

In that theory i might agree but in security policy and refpolicy there
are also other things to consider. Like does the perceived benefit
outweigh the overhead and does it warrant doubling the amount of dbus calls.

I will leave that decision up to refpolicy maintainer (which i think is
currently on holiday or something)

> Best regards,
> 
> Guido
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk1BN+gACgkQMlxVo39jgT+V5QCgsRfpj0vVUm+6lF48PZ3Dqwhr
1vAAn13o37F5YrfIH2+uDDPP79OysYR0
=60Er
-----END PGP SIGNATURE-----

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

[Guido Trentalancia]

Hello Dominick !

On Thu, 27/01/2011 at 10.16 +0100, Dominick Grift wrote:
> On 01/27/2011 01:37 AM, Guido Trentalancia wrote:
> > On Wed, 26/01/2011 at 18.36 +0100, Dominick Grift wrote:
> >> On 01/26/2011 06:28 PM, Guido Trentalancia wrote:
> >>> Hello Dominick !
> >>>
> >>> On Wed, 26/01/2011 at 09.17 +0100, Dominick Grift wrote:
> >>>> On 01/26/2011 01:41 AM, Guido Trentalancia 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.

But then the corecmd_bin_domtrans() interface mentions that "this is not
suggested". What does that comment mean exactly ? Isn't that still
better than allowing system_dbusd_t bin_t:file execute ?

Regards,

Guido

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

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/27/2011 09:36 PM, Guido Trentalancia wrote:
> Hello Dominick !
> 
> On Thu, 27/01/2011 at 10.16 +0100, Dominick Grift wrote:
>> On 01/27/2011 01:37 AM, Guido Trentalancia wrote:
>>> On Wed, 26/01/2011 at 18.36 +0100, Dominick Grift wrote:
>>>> On 01/26/2011 06:28 PM, Guido Trentalancia wrote:
>>>>> Hello Dominick !
>>>>>
>>>>> On Wed, 26/01/2011 at 09.17 +0100, Dominick Grift wrote:
>>>>>> On 01/26/2011 01:41 AM, Guido Trentalancia 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.

> But then the corecmd_bin_domtrans() interface mentions that "this is not
> suggested". What does that comment mean exactly ? Isn't that still
> better than allowing system_dbusd_t bin_t:file execute ?
> 
> Regards,
> 
> Guido
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk1B2KoACgkQMlxVo39jgT9siQCgsErYCcpB3aRwNxytZWBm85bd
0tUAnRl25OMqOu84uAPW2jzOKANh/THQ
=OxjA
-----END PGP SIGNATURE-----

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

[Guido Trentalancia]

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.

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)
 
 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)
+')
+
+optional_policy(`
+	xserver_read_xdm_files(policykit_t)
+	xserver_xdm_dbus_send(policykit_t)
+')
+
 ########################################
 #
 # 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)
 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).

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 ?

Regards,

Guido

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

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

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

[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

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

[Dominick Grift]

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

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

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

[Guido Trentalancia]

On Fri, 28/01/2011 at 19.47 +0100, Dominick Grift wrote:
> 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?

Oops, sorry, forgot to reply on that. SystemToolsBackend.pl is a perl
script being run by dbus after the latter has read the relative .service
files which are generally placed in /usr/share/dbus-1/system-services

Dbus might also run the binary
executable /usr/sbin/system-tools-backends which at the moment is
labelled generically bin_t so needs corecmd_exec_bin call.

I don't think a dbus_system_domain() call is possible at the moment
because there is no module (and no domain, no contexts) for s-t-b (let's
call system-tools-backends that way for short).

This will be probably carried out in a future set of patches which aim
to target less essential things. For the moment, I would just drop any
support for s-t-b as corecmd_exec_{bin,shell} for DBus might not be
desirable for everyone and s-t-b is not essential for running X and
gnome.

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

Indeed !

--- refpolicy-git-24012011/policy/modules/services/policykit.fc	2011-01-08 19:07:21.280747356 +0100
+++ refpolicy-git-24012011-new/policy/modules/services/policykit.fc	2011-01-29 03:56:39.452384582 +0100
@@ -11,5 +11,6 @@
 /var/lib/misc/PolicyKit.reload			gen_context(system_u:object_r:policykit_reload_t,s0)
 /var/lib/PolicyKit(/.*)?			gen_context(system_u:object_r:policykit_var_lib_t,s0)
 /var/lib/PolicyKit-public(/.*)?			gen_context(system_u:object_r:policykit_var_lib_t,s0)
+/var/lib/polkit-1(/.*)?				gen_context(system_u:object_r:policykit_var_lib_t,s0)
 /var/run/PolicyKit(/.*)?			gen_context(system_u:object_r:policykit_var_run_t,s0)

Hmm. Refpolicy will look much better after all this work !

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

Hold on a second. But the inner nesting sounds useless to me because
both options are triggered by the presence of the xserver module.

Not that it's not going to work, but the above appears to me equivalent
to:

optional_policy(`
 	xserver_read_xdm_files(policykit_t)
	xserver_xdm_dbus_send(policykit_t)
')

and so I suppose it will be expanded the same in all possible cases (in
particular the case xserver=module and dbus=off doesn't seem to break
the build).

> >> 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.
> 
> Just leave it user_home_t for now. Because we need consensus about this
> first.

Well we need consensus about everything in this patch set as we cannot
commit ourselves anyway and because, of course, everybody needs to be
happy with it.

But I bet in this case it will just be a matter of chosing a name...
what else could be argued ?

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

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

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/29/2011 04:49 AM, Guido Trentalancia wrote:
> On Fri, 28/01/2011 at 19.47 +0100, Dominick Grift wrote:
>> 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?
> 
> Oops, sorry, forgot to reply on that. SystemToolsBackend.pl is a perl
> script being run by dbus after the latter has read the relative .service
> files which are generally placed in /usr/share/dbus-1/system-services
> 
> Dbus might also run the binary
> executable /usr/sbin/system-tools-backends which at the moment is
> labelled generically bin_t so needs corecmd_exec_bin call.

We need to create a new module/domain for this suite in my biew

> I don't think a dbus_system_domain() call is possible at the moment
> because there is no module (and no domain, no contexts) for s-t-b (let's
> call system-tools-backends that way for short).
> 
> This will be probably carried out in a future set of patches which aim
> to target less essential things. For the moment, I would just drop any
> support for s-t-b as corecmd_exec_{bin,shell} for DBus might not be
> desirable for everyone and s-t-b is not essential for running X and
> gnome.
> 
>>>>> 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)
> 
> Indeed !
> 
> --- refpolicy-git-24012011/policy/modules/services/policykit.fc	2011-01-08 19:07:21.280747356 +0100
> +++ refpolicy-git-24012011-new/policy/modules/services/policykit.fc	2011-01-29 03:56:39.452384582 +0100
> @@ -11,5 +11,6 @@
>  /var/lib/misc/PolicyKit.reload			gen_context(system_u:object_r:policykit_reload_t,s0)
>  /var/lib/PolicyKit(/.*)?			gen_context(system_u:object_r:policykit_var_lib_t,s0)
>  /var/lib/PolicyKit-public(/.*)?			gen_context(system_u:object_r:policykit_var_lib_t,s0)
> +/var/lib/polkit-1(/.*)?				gen_context(system_u:object_r:policykit_var_lib_t,s0)
>  /var/run/PolicyKit(/.*)?			gen_context(system_u:object_r:policykit_var_run_t,s0)
> 
> Hmm. Refpolicy will look much better after all this work !
> 
>>>>>  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.
> 
> Hold on a second. But the inner nesting sounds useless to me because
> both options are triggered by the presence of the xserver module.

optional policy can be confusing and complex issue believe me. But it is
important to do it right. I admit that i am also sometimes confused by
it so i usually just test and see what works. But my policy is much more
complex in many cases and so i often hit optional policy issues.

> 
> Not that it's not going to work, but the above appears to me equivalent
> to:
> 
> optional_policy(`
>  	xserver_read_xdm_files(policykit_t)
> 	xserver_xdm_dbus_send(policykit_t)
> ')

I do not think (but forgive  me if i am wrong) that the above is the
same. You can have xserver installed and not dbus. for policy kit both
may be equally optional. even if you have xserver installed you may
still not have dbus installed.

> 
> and so I suppose it will be expanded the same in all possible cases (in
> particular the case xserver=module and dbus=off doesn't seem to break
> the build).

but does it install as well? i guess it just may because the dbus class
is in the access vectors file, but if you would remove it also there
them it will not work i guess.

Anyways this is tough matter. Ive some experience with the complexity of
optional policy and so i do what i think is right, to keep stuff as
modular as possible. but i admit that i also make errors wrt this. so i
may just be wrong.

What ever you do make sure it stays as modular as possible. Meaning in
this care. would it still work if you do semodule -d dbus?


> 
>>>> 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.
>>
>> Just leave it user_home_t for now. Because we need consensus about this
>> first.
> 
> Well we need consensus about everything in this patch set as we cannot
> commit ourselves anyway and because, of course, everybody needs to be
> happy with it.
> 
> But I bet in this case it will just be a matter of chosing a name...
> what else could be argued ?

You'd be surprised about all the things that can be argued about. But
sure, go ahead and implement what you think is right. I did so as well
in my branch.

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

iEYEARECAAYFAk1D0GUACgkQMlxVo39jgT+jEACeP9GJcWRP6Ah5ixu/EWcVBc7+
mvEAn2rOQc2IdAmI4uNI8wOPMtIqTYhD
=8C5j
-----END PGP SIGNATURE-----

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

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/26/2011 06:28 PM, Guido Trentalancia wrote:
> Hello Dominick !
> 
> On Wed, 26/01/2011 at 09.17 +0100, Dominick Grift wrote:
>> On 01/26/2011 01:41 AM, Guido Trentalancia 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)

When you make dbus transition to policykit_t by calling the
dbus_system_domain(), then that may affect other changes you made to the
dbus module.

for example:

 +allow system_dbusd_t self:capability { dac_override setgid setpcap
setuid sys_ptrace };

This might no longer be needed. Maybe policykit needed it?

same goes for the other changes (system-tools-backends)

So i would test the dbus_system_domain() and remove all added policy
from bdus module and then see if you can reproduce any of it, since the
whole scenario changed by specifying the domain transition.



>>>>>>>  
>>>>>>>  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.
>  
>>>>> and this is the log:
>>>>>
>>>>> type=AVC msg=audit(1294879948.810:42): avc:  denied  { execute } for
>>>>> pid=2966 comm="dbus-daemon-lau" name="SystemToolsBackends.pl" dev=dm-1
>>>>> ino=442334 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
>>>>> tcontext=system_u:object_r:usr_t:s0 tclass=file
>>>>>
>>>>> for the moment I have just written a comment in the TE file. Otherwise,
>>>>> we should relabel the perl script. What do you suggest ?
>>>>>
>>>>>>> +files_read_var_lib_files(system_dbusd_t)
>>>>>>> +files_var_log_append(system_dbusd_t)
>>>>>>
>>>>>> Which log is it appending to?
>>>>>
>>>>> Can't find the logs. Again, I can remove and test again, so we might get
>>>>> a better insight. Will let you know shortly.
>>>
>>> In any case, I had re-invented the wheel with those files_*_var_log_*
>>> interfaces. They are already available in the logging module, so all of
>>> them have now disappeared.
>>
>> Still question remains, which log files is it appending?
> 
> That is not showing up anymore since I had removed it. So at the moment
> I can't tell you anything more.
> 
> There is something new in another module (devicekit):
> fs_getattr_xattr_fs permissions needed both in devicekit_{disk,power}_t.
> That was [9/19] for reference and I also wrote a short note in that
> thread.
> 
> So, we have almost finished tidying up things.
> 
> What's next ?
> 
> Regards,
> 
> Guido
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk1AXpsACgkQMlxVo39jgT9psQCgop2D2UC+nUV1RgB7/JQuUxDU
9IEAnjYk8LqbfHvtQ1eaK3w1PWArBSym
=zemB
-----END PGP SIGNATURE-----