: missing file context for system-tools-backends (gnome)

I think the following file context is still missing in current reference policy for an optional Gnome package (that shouldn't need its own policy):

Add the generic binary executable label to the script from System Tools Backends.

Signed-off-by Guido Trentalancia <[email protected]>

---
 policy/modules/contrib/gnome.fc |    2 ++
 1 file changed, 2 insertions(+)

_______________________________________________
refpolicy mailing list
refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy

Quoted 16 lines · Guido Trentalancia

I think the following file context is still missing in current reference policy for an optional Gnome package (that shouldn't need its own policy):

Add the generic binary executable label to the script from System Tools Backends.

Signed-off-by Guido Trentalancia <[email protected]>

---
 policy/modules/contrib/gnome.fc |    2 ++
 1 file changed, 2 insertions(+)

policy/modules/contrib/gnome.fc HOME_DIR/\.gnome2(/.*)? gen_context(sys · line 11

Quoted 5 lines

policy/modules/contrib/gnome.fc +2 -0

@@ -7,3 +7,5 @@ HOME_DIR/\.gnome2(/.*)?		gen_context(sys
 /tmp/gconfd-USER/.*	--	gen_context(system_u:object_r:gconf_tmp_t,s0)
 
 /usr/libexec/gconfd-2 	--	gen_context(system_u:object_r:gconfd_exec_t,s0)
+
+/usr/share/system-tools-backends-2.0/scripts/SystemToolsBackends.pl	--	gen_context(system_u:object_r:bin_t,s0)

This specification only applies to "-2.0". Can you make it more generic?

Maybe something like:

/usr/share/system-tools-backends.*/scripts/SystemToolsBackends.pl

will work?

Hello Dominick.

Quoted 25 lines · Dominick Grift

Quoted 16 lines · Guido Trentalancia

I think the following file context is still missing in current reference policy for an optional Gnome package (that shouldn't need its own policy):

Add the generic binary executable label to the script from System Tools Backends.

Signed-off-by Guido Trentalancia <[email protected]>

---
 policy/modules/contrib/gnome.fc |    2 ++
 1 file changed, 2 insertions(+)

policy/modules/contrib/gnome.fc HOME_DIR/\.gnome2(/.*)? gen_context(sys · line 11

Quoted 5 lines

policy/modules/contrib/gnome.fc +2 -0

@@ -7,3 +7,5 @@ HOME_DIR/\.gnome2(/.*)?		gen_context(sys
 /tmp/gconfd-USER/.*	--	gen_context(system_u:object_r:gconf_tmp_t,s0)
 
 /usr/libexec/gconfd-2 	--	gen_context(system_u:object_r:gconfd_exec_t,s0)
+
+/usr/share/system-tools-backends-2.0/scripts/SystemToolsBackends.pl	--	gen_context(system_u:object_r:bin_t,s0)

This specification only applies to "-2.0". Can you make it more generic?

Quoted 5 lines

Maybe something like:

/usr/share/system-tools-backends.*/scripts/SystemToolsBackends.pl

will work?

Yes, good point.

Also, it would better fit into the dbus module rather than the gnome one.

And I think when it is actually getting used, for example by gnome-system-tools, it needs at least some policy modifications to the dbus module (e.g. corecmd_exec_shell+corecmd_exec_bin), so it's a bit more complicated than just that.

Perhaps, this is a better starting point ?

policy/modules/contrib/dbus.fc +4 -0

@@ -8,10 +8,14 @@
 /usr/bin/dbus-daemon(-1)? --	gen_context(system_u:object_r:dbusd_exec_t,s0)
 /usr/libexec/dbus-daemon-launch-helper -- gen_context(system_u:object_r:dbusd_exec_t,s0)
 
+/usr/share/system-tools-backends.*/scripts/SystemToolsBackends.pl	--	gen_context(system_u:object_r:bin_t,s0)
+
 /var/lib/dbus(/.*)?		gen_context(system_u:object_r:system_dbusd_var_lib_t,s0)
 
 /var/run/dbus(/.*)?		gen_context(system_u:object_r:system_dbusd_var_run_t,s0)
 
+/var/cache/system-tools-backends(/.*)?	gen_context(system_u:object_r:system_dbusd_var_run_t,s0)
+
 ifdef(`distro_redhat',`
 /var/named/chroot/var/run/dbus(/.*)?	gen_context(system_u:object_r:system_dbusd_var_run_t,s0)
 ')

policy/modules/contrib/dbus.te +13 -0

@@ -9,6 +9,13 @@ gen_require(`
 # Delcarations
 #
 
+## <desc>
+## <p>
+## Enable support for system-tools-backends.
+## </p>
+## </desc>
+gen_tunable(allow_system_tools_backends, false)
+
 attribute dbusd_unconfined;
 attribute session_bus_type;
 

@@ -112,6 +119,12 @@ 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
+tunable_policy(`allow_system_tools_backends',`
+	corecmd_exec_bin(system_dbusd_t)
+	corecmd_exec_shell(system_dbusd_t)
+')
+
 domain_use_interactive_fds(system_dbusd_t)
 domain_read_all_domains_state(system_dbusd_t)
 

Regards,

Guido

Quoted 39 lines · Guido Trentalancia

Hello Dominick.

Quoted 25 lines · Dominick Grift

Quoted 16 lines · Guido Trentalancia

I think the following file context is still missing in current reference policy for an optional Gnome package (that shouldn't need its own policy):

Add the generic binary executable label to the script from System Tools Backends.

Signed-off-by Guido Trentalancia <[email protected]>

---
 policy/modules/contrib/gnome.fc |    2 ++
 1 file changed, 2 insertions(+)

policy/modules/contrib/gnome.fc HOME_DIR/\.gnome2(/.*)? gen_context(sys · line 11

Quoted 5 lines

policy/modules/contrib/gnome.fc +2 -0

@@ -7,3 +7,5 @@ HOME_DIR/\.gnome2(/.*)?		gen_context(sys
 /tmp/gconfd-USER/.*	--	gen_context(system_u:object_r:gconf_tmp_t,s0)
 
 /usr/libexec/gconfd-2 	--	gen_context(system_u:object_r:gconfd_exec_t,s0)
+
+/usr/share/system-tools-backends-2.0/scripts/SystemToolsBackends.pl	--	gen_context(system_u:object_r:bin_t,s0)

This specification only applies to "-2.0". Can you make it more generic?

Quoted 5 lines

Maybe something like:

/usr/share/system-tools-backends.*/scripts/SystemToolsBackends.pl

will work?

Yes, good point.

Also, it would better fit into the dbus module rather than the gnome one.

Quoted 6 lines

And I think when it is actually getting used, for example by gnome-system-tools, it needs at least some policy modifications to the dbus module (e.g. corecmd_exec_shell+corecmd_exec_bin), so it's a bit more complicated than just that.

Perhaps, this is a better starting point ?

I dont know what this package actually is except to its description

"a set of cross-platform modules for Linux, FreeBSD and other Unix systems. The backends provide an common DBus interface to all platforms to modify or read the system configuration in a distro independent fashion. "

Looking at the fedora policy seems it only needs:

# needed for system-tools-backends
corecmd_exec_shell(system_dbusd_t)

Whether this should allowed conditionally is debatable i guess.

Fedora allows it unconditionally.

I guess fedora decided to run this in the system_dbusd_t domain rather than in a private domain. I am not sure why that was decided and if thats optimal.

Also dont prepend your boolean names with "allow", prepend it with the name if the module that has it declared or something:
dbus_system_tools_backend_support or something (not even sure whther this belongs in the dbus module)

Description should be something like: "Determine whether system tools backend is supported" or whatever.

Quoted 51 lines

policy/modules/contrib/dbus.fc +4 -0

@@ -8,10 +8,14 @@
 /usr/bin/dbus-daemon(-1)? --	gen_context(system_u:object_r:dbusd_exec_t,s0)
 /usr/libexec/dbus-daemon-launch-helper -- gen_context(system_u:object_r:dbusd_exec_t,s0)
 
+/usr/share/system-tools-backends.*/scripts/SystemToolsBackends.pl	--	gen_context(system_u:object_r:bin_t,s0)
+
 /var/lib/dbus(/.*)?		gen_context(system_u:object_r:system_dbusd_var_lib_t,s0)
 
 /var/run/dbus(/.*)?		gen_context(system_u:object_r:system_dbusd_var_run_t,s0)
 
+/var/cache/system-tools-backends(/.*)?	gen_context(system_u:object_r:system_dbusd_var_run_t,s0)
+
 ifdef(`distro_redhat',`
 /var/named/chroot/var/run/dbus(/.*)?	gen_context(system_u:object_r:system_dbusd_var_run_t,s0)
 ')

policy/modules/contrib/dbus.te +13 -0

@@ -9,6 +9,13 @@ gen_require(`
 # Delcarations
 #
 
+## <desc>
+## <p>
+## Enable support for system-tools-backends.
+## </p>
+## </desc>
+gen_tunable(allow_system_tools_backends, false)
+
 attribute dbusd_unconfined;
 attribute session_bus_type;
 

@@ -112,6 +119,12 @@ 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
+tunable_policy(`allow_system_tools_backends',`
+	corecmd_exec_bin(system_dbusd_t)
+	corecmd_exec_shell(system_dbusd_t)
+')
+
 domain_use_interactive_fds(system_dbusd_t)
 domain_read_all_domains_state(system_dbusd_t)
 

Regards,

Guido

And by the way the file context specification belongs in corecommands.fc file because of type bin_t.

Quoted 120 lines · Guido Trentalancia

Quoted 39 lines

Hello Dominick.

Quoted 25 lines · Dominick Grift

Quoted 16 lines · Guido Trentalancia

I think the following file context is still missing in current reference policy for an optional Gnome package (that shouldn't need its own policy):

Add the generic binary executable label to the script from System Tools Backends.

Signed-off-by Guido Trentalancia <[email protected]>

---
 policy/modules/contrib/gnome.fc |    2 ++
 1 file changed, 2 insertions(+)

policy/modules/contrib/gnome.fc HOME_DIR/\.gnome2(/.*)? gen_context(sys · line 11

Quoted 5 lines

policy/modules/contrib/gnome.fc +2 -0

@@ -7,3 +7,5 @@ HOME_DIR/\.gnome2(/.*)?		gen_context(sys
 /tmp/gconfd-USER/.*	--	gen_context(system_u:object_r:gconf_tmp_t,s0)
 
 /usr/libexec/gconfd-2 	--	gen_context(system_u:object_r:gconfd_exec_t,s0)
+
+/usr/share/system-tools-backends-2.0/scripts/SystemToolsBackends.pl	--	gen_context(system_u:object_r:bin_t,s0)

This specification only applies to "-2.0". Can you make it more generic?

Quoted 5 lines

Maybe something like:

/usr/share/system-tools-backends.*/scripts/SystemToolsBackends.pl

will work?

Yes, good point.

Also, it would better fit into the dbus module rather than the gnome one.

Quoted 6 lines

And I think when it is actually getting used, for example by gnome-system-tools, it needs at least some policy modifications to the dbus module (e.g. corecmd_exec_shell+corecmd_exec_bin), so it's a bit more complicated than just that.

Perhaps, this is a better starting point ?

I dont know what this package actually is except to its description

"a set of cross-platform modules for Linux, FreeBSD and other Unix systems. The backends provide an common DBus interface to all platforms to modify or read the system configuration in a distro independent fashion. "

Looking at the fedora policy seems it only needs:

# needed for system-tools-backends
corecmd_exec_shell(system_dbusd_t)

Whether this should allowed conditionally is debatable i guess.

Fedora allows it unconditionally.

I guess fedora decided to run this in the system_dbusd_t domain rather than in a private domain. I am not sure why that was decided and if thats optimal.

Also dont prepend your boolean names with "allow", prepend it with the name if the module that has it declared or something:
dbus_system_tools_backend_support or something (not even sure whther this belongs in the dbus module)

Description should be something like: "Determine whether system tools backend is supported" or whatever.

Quoted 45 lines

policy/modules/contrib/dbus.fc +4 -0

@@ -8,10 +8,14 @@
 /usr/bin/dbus-daemon(-1)? --	gen_context(system_u:object_r:dbusd_exec_t,s0)
 /usr/libexec/dbus-daemon-launch-helper -- gen_context(system_u:object_r:dbusd_exec_t,s0)
 
+/usr/share/system-tools-backends.*/scripts/SystemToolsBackends.pl	--	gen_context(system_u:object_r:bin_t,s0)
+
 /var/lib/dbus(/.*)?		gen_context(system_u:object_r:system_dbusd_var_lib_t,s0)
 
 /var/run/dbus(/.*)?		gen_context(system_u:object_r:system_dbusd_var_run_t,s0)
 
+/var/cache/system-tools-backends(/.*)?	gen_context(system_u:object_r:system_dbusd_var_run_t,s0)
+
 ifdef(`distro_redhat',`
 /var/named/chroot/var/run/dbus(/.*)?	gen_context(system_u:object_r:system_dbusd_var_run_t,s0)
 ')

policy/modules/contrib/dbus.te +13 -0

@@ -9,6 +9,13 @@ gen_require(`
 # Delcarations
 #
 
+## <desc>
+## <p>
+## Enable support for system-tools-backends.
+## </p>
+## </desc>
+gen_tunable(allow_system_tools_backends, false)
+
 attribute dbusd_unconfined;
 attribute session_bus_type;
 

@@ -112,6 +119,12 @@ 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
+tunable_policy(`allow_system_tools_backends',`
+	corecmd_exec_bin(system_dbusd_t)
+	corecmd_exec_shell(system_dbusd_t)
+')
+
 domain_use_interactive_fds(system_dbusd_t)
 domain_read_all_domains_state(system_dbusd_t)

Hello Dominick.

Quoted 2 lines · Dominick Grift

And by the way the file context specification belongs in corecommands.fc file because of type bin_t.

I am not sure why you suggest a different name for the boolean, when the rest of the policy uses the "allow_" prefix for booleans that activate/deactivate support for components/packages.

However, here is a revised version with the amendments:

--- refpolicy-04062012/policy/modules/kernel/corecommands.fc 2012-05-29
21:13:09.426703690 +0200 +++ refpolicy-04062012-system-tools-backends/policy/modules/kernel/corecommands.fc

2012-06-21 20:30:47.631775829 +0200 @@ -295,6 +295,7 @@

ifdef(distro_gentoo', /usr/share/shorewall-lite(/.*)? gen_context(system_u:object_r:bin_t,s0) /usr/share/shorewall6-lite(/.*)? gen_context(system_u:object_r:bin_t,s0) /usr/share/spamassassin/sa-update\.cron gen_context(system_u:object_r:bin_t,s0)
+/usr/share/system-tools-backends.*/scripts/SystemToolsBackends.pl --
gen_context(system_u:object_r:bin_t,s0) /usr/share/turboprint/lib(/.*)? --
gen_context(system_u:object_r:bin_t,s0) /usr/share/vhostmd/scripts(/.*)? gen_context(system_u:object_r:bin_t,s0)

--- refpolicy-04062012/policy/modules/contrib/dbus.fc 2011-09-09
18:29:23.566610878 +0200 +++ refpolicy-04062012-system-tools-backends/policy/modules/contrib/dbus.fc

2012-06-21 20:30:57.117774699 +0200 @@ -12,6 +12,8 @@

/var/run/dbus(/.*)? gen_context(system_u:object_r:system_dbusd_var_run_t,s0)

+/var/cache/system-tools-backends(/.*)? gen_context(system_u:object_r:system_dbusd_var_run_t,s0) + ifdef(distro_redhat', /var/named/chroot/var/run/dbus(/.*)? gen_context(system_u:object_r:system_dbusd_var_run_t,s0) ') ---
refpolicy-04062012/policy/modules/contrib/dbus.te 2011-09-09
18:29:23.566610878 +0200 +++ refpolicy-04062012-system-tools-backends/policy/modules/contrib/dbus.te

2012-06-21 20:32:21.612867416 +0200 @@ -9,6 +9,13 @@ gen_require(` #

Delcarations #

+## <desc> +## <p> +## Determine whether system-tools-backends is supported. +## </p> +## </desc> +gen_tunable(system_tools_backends_support, true) + attribute dbusd_unconfined; attribute session_bus_type;

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

@@ -112,6 +119,12 @@ 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 
+tunable_policy(`allow_system_tools_backends',` +
 corecmd_exec_bin(system_dbusd_t) +	corecmd_exec_shell(system_dbusd_t) +') 
+ domain_use_interactive_fds(system_dbusd_t) 
 domain_read_all_domains_state(system_dbusd_t)
 

Regards,

Guido

Quoted 112 lines · Dominick Grift

Quoted 111 lines · Guido Trentalancia

Quoted 42 lines

Hello Dominick.

Quoted 25 lines · Dominick Grift

Quoted 14 lines · Guido Trentalancia

I think the following file context is still missing in current reference policy for an optional Gnome package (that shouldn't need its own policy):

Add the generic binary executable label to the script from System Tools Backends.

Signed-off-by Guido Trentalancia <[email protected]> ---

policy/modules/contrib/gnome.fc | 2 ++ 1 file changed, 2
insertions(+)

--- refpolicy-04062012/policy/modules/contrib/gnome.fc 2011-09-09
18:29:23.571610910 +0200 +++ refpolicy-04062012-system-tools-backends/policy/modules/contrib/gnome.fc

Quoted 9 lines

2012-06-20 22:41:01.448465819 +0200 @@ -7,3 +7,5 @@

HOME_DIR/\.gnome2(/.*)? gen_context(sys /tmp/gconfd-USER/.* --
gen_context(system_u:object_r:gconf_tmp_t,s0)

/usr/libexec/gconfd-2 --
gen_context(system_u:object_r:gconfd_exec_t,s0) + +/usr/share/system-tools-backends-2.0/scripts/SystemToolsBackends.pl
-- gen_context(system_u:object_r:bin_t,s0)

Quoted 8 lines

This specification only applies to "-2.0". Can you make it more generic?

Maybe something like:

/usr/share/system-tools-backends.*/scripts/SystemToolsBackends.pl

will work?

Yes, good point.

Also, it would better fit into the dbus module rather than the gnome one.

Quoted 6 lines

And I think when it is actually getting used, for example by gnome-system-tools, it needs at least some policy modifications to the dbus module (e.g. corecmd_exec_shell+corecmd_exec_bin), so it's a bit more complicated than just that.

Perhaps, this is a better starting point ?

I dont know what this package actually is except to its description

"a set of cross-platform modules for Linux, FreeBSD and other Unix systems. The backends provide an common DBus interface to all platforms to modify or read the system configuration in a distro independent fashion. "

Looking at the fedora policy seems it only needs:

# needed for system-tools-backends corecmd_exec_shell(system_dbusd_t)

Whether this should allowed conditionally is debatable i guess.

Fedora allows it unconditionally.

I guess fedora decided to run this in the system_dbusd_t domain rather than in a private domain. I am not sure why that was decided and if thats optimal.

Also dont prepend your boolean names with "allow", prepend it with the name if the module that has it declared or something:
dbus_system_tools_backend_support or something (not even sure whther this belongs in the dbus module)

Description should be something like: "Determine whether system tools backend is supported" or whatever.

Quoted 34 lines

--- refpolicy-04062012/policy/modules/contrib/dbus.fc 2011-09-09
18:29:23.566610878 +0200 +++ refpolicy-04062012-system-tools-backends/policy/modules/contrib/dbus.fc

2012-06-21 19:25:26.577167925 +0200 @@ -8,10 +8,14 @@ 

/usr/bin/dbus-daemon(-1)? --
gen_context(system_u:object_r:dbusd_exec_t,s0)
/usr/libexec/dbus-daemon-launch-helper --
gen_context(system_u:object_r:dbusd_exec_t,s0)

+/usr/share/system-tools-backends.*/scripts/SystemToolsBackends.pl --
gen_context(system_u:object_r:bin_t,s0) + /var/lib/dbus(/.*)? gen_context(system_u:object_r:system_dbusd_var_lib_t,s0)

/var/run/dbus(/.*)? gen_context(system_u:object_r:system_dbusd_var_run_t,s0)

+/var/cache/system-tools-backends(/.*)? gen_context(system_u:object_r:system_dbusd_var_run_t,s0) + ifdef(distro_redhat', /var/named/chroot/var/run/dbus(/.*)? gen_context(system_u:object_r:system_dbusd_var_run_t,s0) ') ---
refpolicy-04062012/policy/modules/contrib/dbus.te 2011-09-09
18:29:23.566610878 +0200 +++ refpolicy-04062012-system-tools-backends/policy/modules/contrib/dbus.te

2012-06-21 19:22:02.830368908 +0200 @@ -9,6 +9,13 @@ gen_require(` #

Delcarations #

+## <desc> +## <p> +## Enable support for system-tools-backends. +## </p> +## </desc> +gen_tunable(allow_system_tools_backends, false) + attribute dbusd_unconfined; attribute session_bus_type;

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

@@ -112,6 +119,12 @@ corecmd_list_bin(system_dbusd_t) 
 corecmd_read_bin_pipes(system_dbusd_t) 
 corecmd_read_bin_sockets(system_dbusd_t)
 

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

(quoted diff) +2 -0

+# needed for system-tools-backends 
+tunable_policy(`allow_system_tools_backends',` +

corecmd_exec_bin(system_dbusd_t) +
corecmd_exec_shell(system_dbusd_t) +') +
domain_use_interactive_fds(system_dbusd_t)
domain_read_all_domains_state(system_dbusd_t)

_______________________________________________ refpolicy mailing list refpolicy at oss.tresys.com http://oss.tresys.com/mailman/listinfo/refpolicy

Quoted 39 lines · Guido Trentalancia

Hello Dominick.

Quoted 25 lines · Dominick Grift

Quoted 16 lines · Guido Trentalancia

I think the following file context is still missing in current reference policy for an optional Gnome package (that shouldn't need its own policy):

Add the generic binary executable label to the script from System Tools Backends.

Signed-off-by Guido Trentalancia <[email protected]>

---
 policy/modules/contrib/gnome.fc |    2 ++
 1 file changed, 2 insertions(+)

policy/modules/contrib/gnome.fc HOME_DIR/\.gnome2(/.*)? gen_context(sys · line 11

Quoted 5 lines

policy/modules/contrib/gnome.fc +2 -0

@@ -7,3 +7,5 @@ HOME_DIR/\.gnome2(/.*)?		gen_context(sys
 /tmp/gconfd-USER/.*	--	gen_context(system_u:object_r:gconf_tmp_t,s0)
 
 /usr/libexec/gconfd-2 	--	gen_context(system_u:object_r:gconfd_exec_t,s0)
+
+/usr/share/system-tools-backends-2.0/scripts/SystemToolsBackends.pl	--	gen_context(system_u:object_r:bin_t,s0)

This specification only applies to "-2.0". Can you make it more generic?

Quoted 5 lines

Maybe something like:

/usr/share/system-tools-backends.*/scripts/SystemToolsBackends.pl

will work?

Yes, good point.

Also, it would better fit into the dbus module rather than the gnome one.

Quoted 6 lines

And I think when it is actually getting used, for example by gnome-system-tools, it needs at least some policy modifications to the dbus module (e.g. corecmd_exec_shell+corecmd_exec_bin), so it's a bit more complicated than just that.

Perhaps, this is a better starting point ?

I dont know what this package actually is except to its description

"a set of cross-platform modules for Linux, FreeBSD and other Unix systems. The backends provide an common DBus interface to all platforms to modify or read the system configuration in a distro independent fashion. "

Looking at the fedora policy seems it only needs:

# needed for system-tools-backends
corecmd_exec_shell(system_dbusd_t)

Whether this should allowed conditionally is debatable i guess.

Fedora allows it unconditionally.

I guess fedora decided to run this in the system_dbusd_t domain rather than in a private domain. I am not sure why that was decided and if thats optimal.

Also dont prepend your boolean names with "allow", prepend it with the name if the module that has it declared or something:
dbus_system_tools_backend_support or something (not even sure whther this belongs in the dbus module)

Description should be something like: "Determine whether system tools backend is supported" or whatever.

Quoted 47 lines

policy/modules/contrib/dbus.fc +4 -0

@@ -8,10 +8,14 @@
 /usr/bin/dbus-daemon(-1)? --	gen_context(system_u:object_r:dbusd_exec_t,s0)
 /usr/libexec/dbus-daemon-launch-helper -- gen_context(system_u:object_r:dbusd_exec_t,s0)
 
+/usr/share/system-tools-backends.*/scripts/SystemToolsBackends.pl	--	gen_context(system_u:object_r:bin_t,s0)
+
 /var/lib/dbus(/.*)?		gen_context(system_u:object_r:system_dbusd_var_lib_t,s0)
 
 /var/run/dbus(/.*)?		gen_context(system_u:object_r:system_dbusd_var_run_t,s0)
 
+/var/cache/system-tools-backends(/.*)?	gen_context(system_u:object_r:system_dbusd_var_run_t,s0)
+
 ifdef(`distro_redhat',`
 /var/named/chroot/var/run/dbus(/.*)?	gen_context(system_u:object_r:system_dbusd_var_run_t,s0)
 ')

policy/modules/contrib/dbus.te +13 -0

@@ -9,6 +9,13 @@ gen_require(`
 # Delcarations
 #
 
+## <desc>
+## <p>
+## Enable support for system-tools-backends.
+## </p>
+## </desc>
+gen_tunable(allow_system_tools_backends, false)
+
 attribute dbusd_unconfined;
 attribute session_bus_type;
 

@@ -112,6 +119,12 @@ 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
+tunable_policy(`allow_system_tools_backends',`
+	corecmd_exec_bin(system_dbusd_t)
+	corecmd_exec_shell(system_dbusd_t)
+')
+
 domain_use_interactive_fds(system_dbusd_t)
 domain_read_all_domains_state(system_dbusd_t)
 

Quoted 3 lines

Regards,

Guido

Quoted 1 line · Guido Trentalancia

Hello Dominick.

Looking at the fedora policy seems it only needs:

# needed for system-tools-backends
corecmd_exec_shell(system_dbusd_t)

And by the way, since you were asking, comecmd_exec_bin is needed when the backends are executed, for example, by gnome-system-tools (since the script had been labelled as a generic binary executable to avoid creating a new module built for the purpose).

Not everybody might want system_dbusd_t to execute binaries, so that's the reason for the boolean.

Regards,

Guido

Quoted 6 lines · Guido Trentalancia

And by the way, since you were asking, comecmd_exec_bin is needed when the backends are executed, for example, by gnome-system-tools (since the script had been labelled as a generic binary executable to avoid creating a new module built for the purpose).

Quoted 7 lines

Not everybody might want system_dbusd_t to execute binaries, so that's the reason for the boolean.

Regards,

Guido

I am still trying to make sense out of all this, but:

I guess we should make system-tools-backends a dbus_system_domain() i.e. make system_dbusd_t domain transition to a private domain type for system-tools-backends when its executable files get executed.

That way we don't have to allow systemd_dbusd_t to run generic binaries.

Consider gnome-system-tools is a GUI that is meant to configure network, system users, shared filesystems or folders and system time. That is why we would need a boolean as a lot of people would probably like to disable such administrative functionality in the policy (it is still possible to have the boolean default to true, as in the latest modification sketch that I posted, for a more usable generic system).

Can you sketch a few lines of policy modifications for the domain transition that you are talking about ? I guess you want to define a new domain, therefore create a new module for system-tools-backends ? And then allow a domain transition from dbus.te to such domain. And perhaps finally label the system-tools-backends perl script with its own ?_exec_t type instead of the generic binary which is more risky ?

Regards,

Guido

Quoted 7 lines · Guido Trentalancia

Consider gnome-system-tools is a GUI that is meant to configure network, system users, shared filesystems or folders and system time. That is why we would need a boolean as a lot of people would probably like to disable such administrative functionality in the policy (it is still possible to have the boolean default to true, as in the latest modification sketch that I posted, for a more usable generic system).

Quoted 6 lines

Can you sketch a few lines of policy modifications for the domain transition that you are talking about ? I guess you want to define a new domain, therefore create a new module for system-tools-backends ? And then allow a domain transition from dbus.te to such domain. And perhaps finally label the system-tools-backends perl script with its own ?_exec_t type instead of the generic binary which is more risky ?

I still can't imagine how this works but:

something like:

type stb_t;
type stb_exec_t;
dbus_system_domain(stb_t, stb_exec_t)
role system_r types stb_t;

and then label the stb executable file(s) type stb_exec_t.

That should tell selinux to perform a domain transition from system_busd_t to stb_t on running files with type stb_exec_t.

You can also find me on irc.freenode.org at #selinux or #fedora-selinux