: patch set to update the git reference policy

policy/modules/services/dbus.te +1 -1

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

policy/modules/services/dbus.te +1 -0

 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

Quoted 21 lines · Guido Trentalancia

policy/modules/services/dbus.te +3 -1

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

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 120

Quoted 1 line

policy/modules/services/dbus.te +1 -0

+files_search_default(system_dbusd_t)

There should not be able default_t type directories. Thus this shouldnt be allowed

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 121

Quoted 1 line

policy/modules/services/dbus.te +1 -0

+files_read_default_files(system_dbusd_t)

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

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

Quoted 27 lines · Dominick Grift

Quoted 12 lines · Guido Trentalancia

policy/modules/services/dbus.te +1 -1

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

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 120

Quoted 10 lines

policy/modules/services/dbus.te +3 -0

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

Quoted 3 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 121

Quoted 1 line

policy/modules/services/dbus.te +1 -0

+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

(quoted diff) +6 -1

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

(quoted diff) +2 -0

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

(quoted diff) +4 -0

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

(quoted diff) +2 -0

+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

Quoted 33 lines · 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...

Quoted 27 lines · Dominick Grift

Quoted 12 lines · Guido Trentalancia

policy/modules/services/dbus.te +1 -1

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

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 120

Quoted 10 lines

policy/modules/services/dbus.te +3 -0

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

Quoted 8 lines

Quoted 3 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 121

Quoted 1 line

policy/modules/services/dbus.te +1 -0

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

Quoted 42 lines

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

(quoted diff) +6 -1

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

(quoted diff) +2 -0

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

(quoted diff) +4 -0

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

(quoted diff) +2 -0

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

Quoted 3 lines

Regards,

Guido

Quoted 38 lines · Dominick Grift

Quoted 36 lines · 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...

Quoted 30 lines · Dominick Grift

Quoted 12 lines · Guido Trentalancia

policy/modules/services/dbus.te +1 -1

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

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 120

Quoted 10 lines

policy/modules/services/dbus.te +3 -0

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

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 121

Quoted 1 line

policy/modules/services/dbus.te +1 -0

+files_read_default_files(system_dbusd_t)

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

Quoted 8 lines

Quoted 4 lines

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.

Quoted 2 lines

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

Quoted 10 lines

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:

Quoted 8 lines

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

Quoted 18 lines · Guido Trentalancia

policy/modules/services/dbus.te +3 -1

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

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 120

Quoted 4 lines

policy/modules/services/dbus.te +1 -0

 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

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 121

Quoted 1 line

policy/modules/services/dbus.te +1 -0

+files_read_default_files(system_dbusd_t)

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

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 124

Quoted 4 lines

policy/modules/services/dbus.te +1 -1

 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?

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 125

Quoted 1 line

policy/modules/services/dbus.te +1 -0

+files_exec_usr_files(system_dbusd_t)

Which usr_t files is it executing?

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 127

Quoted 2 lines

policy/modules/services/dbus.te +2 -0

+files_read_var_lib_files(system_dbusd_t)
+files_var_log_append(system_dbusd_t)

Which log is it appending to?

policy/modules/services/dbus.te optional_policy(` · line 153

Quoted 9 lines

policy/modules/services/dbus.te +1 -0

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

Hi Dominick,

finally I am managing to get into this...

Quoted 19 lines · Dominick Grift

Quoted 18 lines · Guido Trentalancia

policy/modules/services/dbus.te +3 -1

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

Quoted 7 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 120

Quoted 4 lines

policy/modules/services/dbus.te +1 -0

 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.

Quoted 3 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 121

Quoted 1 line

policy/modules/services/dbus.te +1 -0

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

Quoted 6 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 124

Quoted 4 lines

policy/modules/services/dbus.te +1 -1

 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

Quoted 3 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 125

Quoted 1 line

policy/modules/services/dbus.te +1 -0

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

Quoted 4 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 127

Quoted 2 lines

policy/modules/services/dbus.te +2 -0

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

Quoted 5 lines

Quoted 5 lines

policy/modules/services/dbus.te +0 -0

 init_use_fds(system_dbusd_t)
 init_use_script_ptys(system_dbusd_t)

@@ -141,6 +148,7 @@ optional_policy(`
 ')
 

Quoted 4 lines

policy/modules/services/dbus.te optional_policy(` · line 153

Quoted 4 lines

policy/modules/services/dbus.te +1 -0

 optional_policy(`
+	consolekit_read_pid_files(system_dbusd_t)
 	consolekit_dbus_send(system_dbusd_t)
 ')

Regards,

Guido

Quoted 48 lines · Guido Trentalancia

Hi Dominick,

finally I am managing to get into this...

Quoted 19 lines · Dominick Grift

Quoted 18 lines · Guido Trentalancia

policy/modules/services/dbus.te +3 -1

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

Quoted 7 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 120

Quoted 4 lines

policy/modules/services/dbus.te +1 -0

 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.

Quoted 3 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 121

Quoted 1 line

policy/modules/services/dbus.te +1 -0

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

Quoted 6 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 124

Quoted 4 lines

policy/modules/services/dbus.te +1 -1

 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?

Quoted 9 lines

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

Quoted 7 lines

Quoted 3 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 125

Quoted 1 line

policy/modules/services/dbus.te +1 -0

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

Quoted 2 lines

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

Quoted 10 lines

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 ?

Quoted 7 lines

Quoted 4 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 127

Quoted 2 lines

policy/modules/services/dbus.te +2 -0

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

Hello Dominick !

Quoted 59 lines · Dominick Grift

Quoted 48 lines · Guido Trentalancia

Hi Dominick,

finally I am managing to get into this...

Quoted 19 lines · Dominick Grift

Quoted 18 lines · Guido Trentalancia

policy/modules/services/dbus.te +3 -1

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

Quoted 7 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 120

Quoted 4 lines

policy/modules/services/dbus.te +1 -0

 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.

Quoted 3 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 121

Quoted 1 line

policy/modules/services/dbus.te +1 -0

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

Quoted 6 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 124

Quoted 4 lines

policy/modules/services/dbus.te +1 -1

 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?

Quoted 9 lines

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

Quoted 3 lines

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

Quoted 1 line

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 ?

Quoted 14 lines

Quoted 9 lines

Quoted 3 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 125

Quoted 1 line

policy/modules/services/dbus.te +1 -0

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

Quoted 1 line

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.

Quoted 16 lines

Quoted 16 lines

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 ?

Quoted 4 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 127

Quoted 2 lines

policy/modules/services/dbus.te +2 -0

+files_read_var_lib_files(system_dbusd_t)
+files_var_log_append(system_dbusd_t)

Which log is it appending to?

Quoted 2 lines

Quoted 2 lines

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

Quoted 71 lines · Guido Trentalancia

Quoted 59 lines · Dominick Grift

Quoted 48 lines · Guido Trentalancia

Hi Dominick,

finally I am managing to get into this...

Quoted 19 lines · Dominick Grift

Quoted 18 lines · Guido Trentalancia

policy/modules/services/dbus.te +3 -1

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

Quoted 7 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 120

Quoted 4 lines

policy/modules/services/dbus.te +1 -0

 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.

Quoted 3 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 121

Quoted 1 line

policy/modules/services/dbus.te +1 -0

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

Quoted 6 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 124

Quoted 4 lines

policy/modules/services/dbus.te +1 -1

 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?

Quoted 9 lines

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

Quoted 3 lines

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

Quoted 7 lines

Quoted 1 line

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)

Quoted 18 lines

Quoted 7 lines

Quoted 7 lines

Quoted 3 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 125

Quoted 1 line

policy/modules/services/dbus.te +1 -0

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

Quoted 8 lines

Quoted 2 lines

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

Quoted 3 lines

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

Quoted 15 lines

Quoted 15 lines

Quoted 15 lines

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 ?

Quoted 4 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 127

Quoted 2 lines

policy/modules/services/dbus.te +2 -0

+files_read_var_lib_files(system_dbusd_t)
+files_var_log_append(system_dbusd_t)

Which log is it appending to?

Quoted 6 lines

Quoted 2 lines

Quoted 2 lines

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?

Hello Dominick !

Quoted 80 lines · Dominick Grift

Quoted 71 lines · Guido Trentalancia

Quoted 59 lines · Dominick Grift

Quoted 48 lines · Guido Trentalancia

Hi Dominick,

finally I am managing to get into this...

Quoted 19 lines · Dominick Grift

Quoted 18 lines · Guido Trentalancia

policy/modules/services/dbus.te +3 -1

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

Quoted 7 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 120

Quoted 4 lines

policy/modules/services/dbus.te +1 -0

 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.

Quoted 3 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 121

Quoted 1 line

policy/modules/services/dbus.te +1 -0

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

Quoted 6 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 124

Quoted 4 lines

policy/modules/services/dbus.te +1 -1

 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?

Quoted 9 lines

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

Quoted 3 lines

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

Quoted 7 lines

Quoted 1 line

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 ?

Quoted 3 lines

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.

Quoted 18 lines

Quoted 18 lines

Quoted 7 lines

Quoted 7 lines

Quoted 3 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 125

Quoted 1 line

policy/modules/services/dbus.te +1 -0

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

Quoted 8 lines

Quoted 2 lines

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

Quoted 8 lines

Quoted 3 lines

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.

Quoted 15 lines

Quoted 15 lines

Quoted 15 lines

Quoted 15 lines

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 ?

Quoted 4 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 127

Quoted 2 lines

policy/modules/services/dbus.te +2 -0

+files_read_var_lib_files(system_dbusd_t)
+files_var_log_append(system_dbusd_t)

Which log is it appending to?

Quoted 8 lines

Quoted 6 lines

Quoted 2 lines

Quoted 2 lines

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

Quoted 155 lines · Guido Trentalancia

Hello Dominick !

Quoted 80 lines · Dominick Grift

Quoted 71 lines · Guido Trentalancia

Quoted 59 lines · Dominick Grift

Quoted 48 lines · Guido Trentalancia

Hi Dominick,

finally I am managing to get into this...

Quoted 19 lines · Dominick Grift

Quoted 18 lines · Guido Trentalancia

policy/modules/services/dbus.te +3 -1

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

Quoted 7 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 120

Quoted 4 lines

policy/modules/services/dbus.te +1 -0

 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.

Quoted 3 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 121

Quoted 1 line

policy/modules/services/dbus.te +1 -0

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

Quoted 6 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 124

Quoted 4 lines

policy/modules/services/dbus.te +1 -1

 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?

Quoted 9 lines

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

Quoted 3 lines

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

Quoted 7 lines

Quoted 1 line

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 ?

Quoted 3 lines

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.

Quoted 18 lines

Quoted 18 lines

Quoted 7 lines

Quoted 7 lines

Quoted 3 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 125

Quoted 1 line

policy/modules/services/dbus.te +1 -0

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

Quoted 8 lines

Quoted 2 lines

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

Quoted 8 lines

Quoted 3 lines

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.

Quoted 15 lines

Quoted 15 lines

Quoted 15 lines

Quoted 15 lines

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 ?

Quoted 4 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 127

Quoted 2 lines

policy/modules/services/dbus.te +2 -0

+files_read_var_lib_files(system_dbusd_t)
+files_var_log_append(system_dbusd_t)

Which log is it appending to?

Quoted 8 lines

Quoted 6 lines

Quoted 2 lines

Quoted 2 lines

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.

Quoted 1 line

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.

Hi Dominick !

Quoted 156 lines · Dominick Grift

Quoted 155 lines · Guido Trentalancia

Hello Dominick !

Quoted 80 lines · Dominick Grift

Quoted 71 lines · Guido Trentalancia

Quoted 59 lines · Dominick Grift

Quoted 48 lines · Guido Trentalancia

Hi Dominick,

finally I am managing to get into this...

Quoted 19 lines · Dominick Grift

Quoted 18 lines · Guido Trentalancia

policy/modules/services/dbus.te +3 -1

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

Quoted 7 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 120

Quoted 4 lines

policy/modules/services/dbus.te +1 -0

 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.

Quoted 3 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 121

Quoted 1 line

policy/modules/services/dbus.te +1 -0

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

Quoted 6 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 124

Quoted 4 lines

policy/modules/services/dbus.te +1 -1

 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?

Quoted 9 lines

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

Quoted 3 lines

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

Quoted 7 lines

Quoted 1 line

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 ?

Quoted 3 lines

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.

Quoted 18 lines

Quoted 18 lines

Quoted 7 lines

Quoted 7 lines

Quoted 3 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 125

Quoted 1 line

policy/modules/services/dbus.te +1 -0

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

Quoted 8 lines

Quoted 2 lines

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

Quoted 8 lines

Quoted 3 lines

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.

Quoted 15 lines

Quoted 15 lines

Quoted 15 lines

Quoted 15 lines

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 ?

Quoted 4 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 127

Quoted 2 lines

policy/modules/services/dbus.te +2 -0

+files_read_var_lib_files(system_dbusd_t)
+files_var_log_append(system_dbusd_t)

Which log is it appending to?

Quoted 8 lines

Quoted 6 lines

Quoted 2 lines

Quoted 2 lines

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.

Quoted 7 lines

Quoted 1 line

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

Quoted 114 lines · Guido Trentalancia

Quoted 113 lines · Dominick Grift

Quoted 112 lines · Guido Trentalancia

Hello Dominick !

Quoted 80 lines · Dominick Grift

Quoted 71 lines · Guido Trentalancia

Quoted 59 lines · Dominick Grift

Quoted 48 lines · Guido Trentalancia

Hi Dominick,

finally I am managing to get into this...

Quoted 19 lines · Dominick Grift

Quoted 18 lines · Guido Trentalancia

policy/modules/services/dbus.te +3 -1

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

Quoted 7 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 120

Quoted 4 lines

policy/modules/services/dbus.te +1 -0

 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.

Quoted 3 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 121

Quoted 1 line

policy/modules/services/dbus.te +1 -0

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

Quoted 6 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 124

Quoted 4 lines

policy/modules/services/dbus.te +1 -1

 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?

Quoted 9 lines

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

Quoted 3 lines

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

Quoted 7 lines

Quoted 1 line

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 ?

Quoted 3 lines

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.

Quoted 22 lines

Quoted 21 lines

Quoted 7 lines

Quoted 7 lines

Quoted 3 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 125

Quoted 1 line

policy/modules/services/dbus.te +1 -0

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

Quoted 8 lines

Quoted 2 lines

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

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 4 lines

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.

Hello Dominick !

Quoted 120 lines · Dominick Grift

Quoted 119 lines · Guido Trentalancia

Quoted 118 lines · Dominick Grift

Quoted 117 lines · Guido Trentalancia

Hello Dominick !

Quoted 80 lines · Dominick Grift

Quoted 71 lines · Guido Trentalancia

Quoted 59 lines · Dominick Grift

Quoted 48 lines · Guido Trentalancia

Hi Dominick,

finally I am managing to get into this...

Quoted 19 lines · Dominick Grift

Quoted 18 lines · Guido Trentalancia

policy/modules/services/dbus.te +3 -1

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

Quoted 7 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 120

Quoted 4 lines

policy/modules/services/dbus.te +1 -0

 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.

Quoted 3 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 121

Quoted 1 line

policy/modules/services/dbus.te +1 -0

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

Quoted 6 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 124

Quoted 4 lines

policy/modules/services/dbus.te +1 -1

 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?

Quoted 9 lines

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

Quoted 3 lines

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

Quoted 7 lines

Quoted 1 line

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 ?

Quoted 3 lines

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.

Quoted 26 lines

Quoted 14 lines

Quoted 14 lines

Quoted 9 lines

Quoted 3 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 125

Quoted 1 line

policy/modules/services/dbus.te +1 -0

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

Quoted 7 lines

Quoted 1 line

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

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

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

Quoted 117 lines

Quoted 116 lines

Quoted 116 lines

Quoted 116 lines

Quoted 116 lines

Quoted 79 lines

Quoted 71 lines · Dominick Grift

Quoted 59 lines · Guido Trentalancia

Quoted 48 lines

Hi Dominick,

finally I am managing to get into this...

Quoted 19 lines · Dominick Grift

Quoted 18 lines · Guido Trentalancia

policy/modules/services/dbus.te +3 -1

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

Quoted 7 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 120

Quoted 4 lines

policy/modules/services/dbus.te +1 -0

 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.

Quoted 3 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 121

Quoted 1 line

policy/modules/services/dbus.te +1 -0

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

Quoted 6 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 124

Quoted 4 lines

policy/modules/services/dbus.te +1 -1

 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?

Quoted 9 lines

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

Quoted 3 lines

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

Quoted 7 lines

Quoted 1 line

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 ?

Quoted 3 lines

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.

Quoted 18 lines

Quoted 18 lines

Quoted 7 lines

Quoted 7 lines

Quoted 3 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 125

Quoted 1 line

policy/modules/services/dbus.te +1 -0

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

Quoted 8 lines

Quoted 2 lines

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

Quoted 8 lines

Quoted 3 lines

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.

Quoted 4 lines

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.

Hi Dominick !

Thanks so much for getting again back to me with your comments and much valuable suggestions !

Quoted 117 lines · Dominick Grift

Quoted 117 lines

Quoted 116 lines

Quoted 116 lines

Quoted 116 lines

Quoted 116 lines

Quoted 79 lines

Quoted 71 lines · Dominick Grift

Quoted 59 lines · Guido Trentalancia

Quoted 48 lines

Hi Dominick,

finally I am managing to get into this...

Quoted 19 lines · Dominick Grift

Quoted 18 lines · 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)

Quoted 7 lines

Quoted 4 lines

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.

Quoted 3 lines

Quoted 1 line

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

Quoted 6 lines

Quoted 4 lines

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?

Quoted 9 lines

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

Quoted 3 lines

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

Quoted 7 lines

Quoted 1 line

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 ?

Quoted 3 lines

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.

Quoted 18 lines

Quoted 18 lines

Quoted 7 lines

Quoted 7 lines

Quoted 3 lines

Quoted 1 line

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

Quoted 8 lines

Quoted 2 lines

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

Quoted 8 lines

Quoted 3 lines

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.

Quoted 8 lines

Quoted 4 lines

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:

policy/modules/services/policykit.te +2 -2

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

policy/modules/services/policykit.te +0 -0

 auth_use_nsswitch(policykit_t)
 

@@ -69,6 +71,23 @@ miscfiles_read_localization(policykit_t)
 
 userdom_read_all_users_state(policykit_t)
 

policy/modules/services/policykit.te +2 -0

+')
+
 ########################################
 #
 # polkit_auth local policy

policy/modules/services/policykit.if +20 -0

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

policy/modules/apps/gnome.fc +0 -0

 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

Quoted 156 lines · Guido Trentalancia

Hi Dominick !

Thanks so much for getting again back to me with your comments and much valuable suggestions !

Quoted 117 lines · Dominick Grift

Quoted 117 lines

Quoted 116 lines

Quoted 116 lines

Quoted 116 lines

Quoted 116 lines

Quoted 79 lines

Quoted 71 lines · Dominick Grift

Quoted 59 lines · Guido Trentalancia

Quoted 48 lines

Hi Dominick,

finally I am managing to get into this...

Quoted 26 lines · Dominick Grift

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.

Quoted 3 lines

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

Quoted 6 lines

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?

Quoted 9 lines

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

Quoted 3 lines

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

Quoted 7 lines

Quoted 1 line

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 ?

Quoted 3 lines

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.

Quoted 18 lines

Quoted 18 lines

Quoted 7 lines

Quoted 7 lines

Quoted 3 lines

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

Quoted 8 lines

Quoted 2 lines

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

Quoted 8 lines

Quoted 3 lines

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.

Quoted 8 lines

Quoted 4 lines

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)

Quoted 7 lines

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

Quoted 20 lines

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:

policy/modules/services/policykit.te +2 -2

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

policy/modules/services/policykit.te manage_files_pattern(policykit_t, policy · line 64

Quoted 6 lines

policy/modules/services/policykit.te +2 -0

 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?

Quoted 6 lines

policy/modules/services/policykit.te +0 -0

 auth_use_nsswitch(policykit_t)
 

@@ -69,6 +71,23 @@ miscfiles_read_localization(policykit_t)
 
 userdom_read_all_users_state(policykit_t)
 

policy/modules/services/policykit.te miscfiles_read_localization(policykit_t) · line 83

Quoted 10 lines

policy/modules/services/policykit.te +10 -0

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

policy/modules/services/policykit.te miscfiles_read_localization(policykit_t) · line 87

Quoted 4 lines

policy/modules/services/policykit.te +4 -0

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

policy/modules/services/policykit.te miscfiles_read_localization(policykit_t) · line 88

Quoted 1 line

policy/modules/services/policykit.te +1 -0

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

Quoted 33 lines

policy/modules/services/policykit.te +2 -0

+')
+
 ########################################
 #
 # polkit_auth local policy

policy/modules/services/policykit.if +20 -0

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

policy/modules/apps/gnome.fc line 1

Quoted 6 lines

policy/modules/services/policykit.if +0 -0

 ## </summary>

policy/modules/apps/gnome.fc +1 -1

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

Quoted 12 lines

policy/modules/apps/gnome.fc +0 -0

 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

Quoted 5 lines

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.

Quoted 160 lines · Dominick Grift

Quoted 159 lines · Guido Trentalancia

Hi Dominick !

Thanks so much for getting again back to me with your comments and much valuable suggestions !

Quoted 117 lines · Dominick Grift

Quoted 117 lines

Quoted 116 lines

Quoted 116 lines

Quoted 116 lines

Quoted 116 lines

Quoted 79 lines

Quoted 71 lines · Dominick Grift

Quoted 59 lines · Guido Trentalancia

Quoted 57 lines

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

Quoted 3 lines

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

Quoted 7 lines

Quoted 1 line

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 ?

Quoted 3 lines

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.

Quoted 18 lines

Quoted 18 lines

Quoted 7 lines

Quoted 7 lines

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

Quoted 8 lines

Quoted 2 lines

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

Quoted 8 lines

Quoted 3 lines

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.

Quoted 8 lines

Quoted 4 lines

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.

Quoted 8 lines

Quoted 4 lines

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

Quoted 23 lines

Quoted 23 lines

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:

policy/modules/services/policykit.te +3 -2

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

Quoted 5 lines

policy/modules/services/policykit.te manage_files_pattern(policykit_t, policy · line 64

Quoted 3 lines

policy/modules/services/policykit.te +1 -0

 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.

Quoted 6 lines

Quoted 6 lines

policy/modules/services/policykit.te +0 -0

 auth_use_nsswitch(policykit_t)
 

@@ -69,6 +71,23 @@ miscfiles_read_localization(policykit_t)
 
 userdom_read_all_users_state(policykit_t)
 

Quoted 12 lines

policy/modules/services/policykit.te miscfiles_read_localization(policykit_t) · line 83

Quoted 10 lines

policy/modules/services/policykit.te +10 -0

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

Quoted 31 lines

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)

policy/modules/services/policykit.te miscfiles_read_localization(policykit_t) · line 87

Quoted 4 lines

policy/modules/services/policykit.te +4 -0

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

policy/modules/services/policykit.te miscfiles_read_localization(policykit_t) · line 88

Quoted 1 line

policy/modules/services/policykit.te +1 -0

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

')

Quoted 1 line

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

Quoted 37 lines

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.

Quoted 33 lines

policy/modules/services/policykit.te +2 -0

+')
+
 ########################################
 #
 # polkit_auth local policy

policy/modules/services/policykit.if +20 -0

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

Quoted 21 lines

policy/modules/apps/gnome.fc line 1

Quoted 6 lines

policy/modules/services/policykit.if +0 -0

 ## </summary>

policy/modules/apps/gnome.fc +1 -1

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

Quoted 12 lines

policy/modules/apps/gnome.fc +0 -0

 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 ?

Quoted 7 lines

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

Quoted 10 lines

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

Quoted 5 lines

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 ?

Quoted 2 lines

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

Quoted 166 lines · Guido Trentalancia

Quoted 165 lines · Dominick Grift

Quoted 163 lines · Guido Trentalancia

Hi Dominick !

Thanks so much for getting again back to me with your comments and much valuable suggestions !

Quoted 117 lines · Dominick Grift

Quoted 117 lines

Quoted 116 lines

Quoted 116 lines

Quoted 116 lines

Quoted 116 lines

Quoted 79 lines

Quoted 71 lines · Dominick Grift

Quoted 62 lines · 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

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

Quoted 7 lines

Quoted 1 line

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 ?

Quoted 3 lines

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.

Quoted 18 lines

Quoted 18 lines

Quoted 15 lines

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

Quoted 8 lines

Quoted 3 lines

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.

Quoted 8 lines

Quoted 4 lines

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.

Quoted 3 lines

Quoted 3 lines

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?

Quoted 29 lines

Quoted 28 lines

Quoted 18 lines

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:

policy/modules/services/policykit.te +2 -2

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

policy/modules/services/policykit.te manage_files_pattern(policykit_t, policy · line 64

Quoted 8 lines

policy/modules/services/policykit.te +2 -0

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

Quoted 2 lines

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)

Quoted 54 lines

Quoted 6 lines

Quoted 6 lines

policy/modules/services/policykit.te +0 -0

 auth_use_nsswitch(policykit_t)
 

@@ -69,6 +71,23 @@ miscfiles_read_localization(policykit_t)
 
 userdom_read_all_users_state(policykit_t)
 

Quoted 12 lines

policy/modules/services/policykit.te miscfiles_read_localization(policykit_t) · line 83

Quoted 10 lines

policy/modules/services/policykit.te +10 -0

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

Quoted 23 lines

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)

policy/modules/services/policykit.te miscfiles_read_localization(policykit_t) · line 87

Quoted 4 lines

policy/modules/services/policykit.te +4 -0

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

policy/modules/services/policykit.te miscfiles_read_localization(policykit_t) · line 88

Quoted 1 line

policy/modules/services/policykit.te +1 -0

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

Quoted 8 lines

	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

Quoted 2 lines

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.

Quoted 62 lines

Quoted 37 lines

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.

Quoted 33 lines

policy/modules/services/policykit.te +2 -0

+')
+
 ########################################
 #
 # polkit_auth local policy

policy/modules/services/policykit.if +20 -0

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

Quoted 21 lines

policy/modules/apps/gnome.fc line 1

Quoted 6 lines

policy/modules/services/policykit.if +0 -0

 ## </summary>

policy/modules/apps/gnome.fc +1 -1

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

Quoted 12 lines

policy/modules/apps/gnome.fc +0 -0

 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.

Quoted 3 lines

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.

Quoted 25 lines

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 ?

Quoted 7 lines

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

Quoted 4 lines

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

Quoted 8 lines

Quoted 8 lines

Quoted 5 lines

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.

Quoted 167 lines · Dominick Grift

Quoted 166 lines · Guido Trentalancia

Quoted 165 lines · Dominick Grift

Quoted 163 lines · Guido Trentalancia

Hi Dominick !

Thanks so much for getting again back to me with your comments and much valuable suggestions !

Quoted 117 lines · Dominick Grift

Quoted 117 lines

Quoted 116 lines

Quoted 116 lines

Quoted 116 lines

Quoted 116 lines

Quoted 79 lines

Quoted 78 lines · Dominick Grift

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 ?

Quoted 3 lines

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.

Quoted 18 lines

Quoted 18 lines

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

Quoted 8 lines

Quoted 3 lines

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.

Quoted 8 lines

Quoted 4 lines

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.

Quoted 5 lines

Quoted 3 lines

Quoted 3 lines

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.

Quoted 29 lines

Quoted 29 lines

Quoted 28 lines

Quoted 18 lines

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:

policy/modules/services/policykit.te +2 -2

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

policy/modules/services/policykit.te manage_files_pattern(policykit_t, policy · line 64

Quoted 8 lines

policy/modules/services/policykit.te +2 -0

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

Quoted 7 lines

Quoted 2 lines

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 !

policy/modules/services/policykit.fc +1 -0

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

Quoted 67 lines

Quoted 54 lines

Quoted 6 lines

Quoted 6 lines

policy/modules/services/policykit.te +0 -0

 auth_use_nsswitch(policykit_t)
 

@@ -69,6 +71,23 @@ miscfiles_read_localization(policykit_t)
 
 userdom_read_all_users_state(policykit_t)
 

Quoted 12 lines

policy/modules/services/policykit.te miscfiles_read_localization(policykit_t) · line 83

Quoted 10 lines

policy/modules/services/policykit.te +10 -0

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

Quoted 23 lines

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)

policy/modules/services/policykit.te miscfiles_read_localization(policykit_t) · line 87

Quoted 4 lines

policy/modules/services/policykit.te +4 -0

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

policy/modules/services/policykit.te miscfiles_read_localization(policykit_t) · line 88

Quoted 1 line

policy/modules/services/policykit.te +1 -0

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

Quoted 8 lines

	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

Quoted 2 lines

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

')

Quoted 2 lines

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

Quoted 63 lines

Quoted 63 lines

Quoted 38 lines

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.

Quoted 33 lines

policy/modules/services/policykit.te +2 -0

+')
+
 ########################################
 #
 # polkit_auth local policy

policy/modules/services/policykit.if +20 -0

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

Quoted 21 lines

policy/modules/apps/gnome.fc line 1

Quoted 6 lines

policy/modules/services/policykit.if +0 -0

 ## </summary>

policy/modules/apps/gnome.fc +1 -1

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

Quoted 12 lines

policy/modules/apps/gnome.fc +0 -0

 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.

Quoted 6 lines

Quoted 3 lines

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 ?

Quoted 31 lines

Quoted 31 lines

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 ?

Quoted 7 lines

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

Quoted 10 lines

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

Quoted 5 lines

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 ?

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

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

Hello Dominick !

Quoted 13 lines · Dominick Grift

Quoted 12 lines · Guido Trentalancia

Quoted 11 lines · Dominick Grift

Quoted 10 lines · Guido Trentalancia

Hi Dominick,

finally I am managing to get into this...

Quoted 5 lines · Dominick Grift

Quoted 4 lines · Guido Trentalancia

policy/modules/services/dbus.te +0 -0

@@ -52,7 +52,7 @@ ifdef(`enable_mls',`
 

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

policy/modules/services/dbus.te +1 -1

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

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 115

Quoted 8 lines

policy/modules/services/dbus.te +2 -0

 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)

Quoted 54 lines

Quoted 46 lines

Quoted 35 lines

Quoted 25 lines

Quoted 8 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 119

Quoted 5 lines

policy/modules/services/dbus.te +1 -0

 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.

Quoted 3 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 120

Quoted 1 line

policy/modules/services/dbus.te +1 -0

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

Quoted 6 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 123

Quoted 4 lines

policy/modules/services/dbus.te +1 -1

 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?

Quoted 9 lines

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

Quoted 3 lines

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

Quoted 7 lines

Quoted 1 line

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 ?

Quoted 3 lines

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.

Quoted 18 lines

Quoted 18 lines

Quoted 7 lines

Quoted 7 lines

Quoted 3 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 124

Quoted 1 line

policy/modules/services/dbus.te +1 -0

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

Quoted 8 lines

Quoted 2 lines

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

Quoted 8 lines

Quoted 3 lines

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.

Quoted 15 lines

Quoted 15 lines

Quoted 15 lines

Quoted 15 lines

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 ?

Quoted 4 lines

policy/modules/services/dbus.te auth_read_pam_console_data(system_dbusd_ · line 126

Quoted 2 lines

policy/modules/services/dbus.te +2 -0

+files_read_var_lib_files(system_dbusd_t)
+files_var_log_append(system_dbusd_t)

Which log is it appending to?

Quoted 8 lines

Quoted 6 lines

Quoted 2 lines

Quoted 2 lines

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