[refpolicy] [PATCH]: missing file context for system-tools-backends (gnome)

[refpolicy] [PATCH]: missing file context for system-tools-backends (gnome)

[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 <guido@trentalancia.com>
---
 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	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)

[refpolicy] [PATCH]: missing file context for system-tools-backends (gnome)

[Dominick Grift]

On Wed, 2012-06-20 at 23:03 +0200, Guido Trentalancia wrote:
> 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 <guido@trentalancia.com>
> ---
>  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	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)
> 

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?

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

[refpolicy] [PATCH]: missing file context for system-tools-backends (gnome)

[Guido Trentalancia]

Hello Dominick.

On Thu, 2012-06-21 at 10:41 +0200, Dominick Grift wrote:
> On Wed, 2012-06-20 at 23:03 +0200, Guido Trentalancia wrote:
> > 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 <guido@trentalancia.com>
> > ---
> >  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	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)
> > 
> 
> 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.

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 ?

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

[refpolicy] [PATCH]: missing file context for system-tools-backends (gnome)

[Dominick Grift]

On Thu, 2012-06-21 at 19:38 +0200, Guido Trentalancia wrote:
> Hello Dominick.
> 
> On Thu, 2012-06-21 at 10:41 +0200, Dominick Grift wrote:
> > On Wed, 2012-06-20 at 23:03 +0200, Guido Trentalancia wrote:
> > > 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 <guido@trentalancia.com>
> > > ---
> > >  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	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)
> > > 
> > 
> > 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.
> 
> 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.

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

[refpolicy] [PATCH]: missing file context for system-tools-backends (gnome)

[Dominick Grift]

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

On Thu, 2012-06-21 at 19:58 +0200, Dominick Grift wrote:
> On Thu, 2012-06-21 at 19:38 +0200, Guido Trentalancia wrote:
> > Hello Dominick.
> > 
> > On Thu, 2012-06-21 at 10:41 +0200, Dominick Grift wrote:
> > > On Wed, 2012-06-20 at 23:03 +0200, Guido Trentalancia wrote:
> > > > 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 <guido@trentalancia.com>
> > > > ---
> > > >  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	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)
> > > > 
> > > 
> > > 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.
> > 
> > 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.
> 
> > --- 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;
> >  
> > @@ -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
> > 
> 
> 

[refpolicy] [PATCH]: missing file context for system-tools-backends (gnome)

[Guido Trentalancia]

On Thu, 2012-06-21 at 19:58 +0200, Dominick Grift wrote:
> On Thu, 2012-06-21 at 19:38 +0200, Guido Trentalancia wrote:
> > Hello Dominick.
> > 
> > On Thu, 2012-06-21 at 10:41 +0200, Dominick Grift wrote:
> > > On Wed, 2012-06-20 at 23:03 +0200, Guido Trentalancia wrote:
> > > > 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 <guido@trentalancia.com>
> > > > ---
> > > >  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	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)
> > > > 
> > > 
> > > 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.
> > 
> > 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.

You're right, it's part of Gnome. Perhaps the boolean could be set to
default to true ?

The point is that it hasn't got its own module so it runs as
system_dbus_t and it's not strictly required to run Gnome either.

Finally, I haven't got a clear picture of how wide it is used.

> Fedora allows it unconditionally.

Yes, it allows corecmd_exec_shell unconditionally as in your quote. A
very strict, limited functionality policy might not want to allow that
for an auxiliary package.

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

It's probably not optimal, but there are time and cost constraints too.
With the boolean availability, we could optimize it a little further at
virtually no cost.

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

That can be easily modified... It's not part of DBus. It's part of
Gnome, it uses DBus.

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

Regards,

Guido

[refpolicy] [PATCH v2]: missing file context for system-tools-backends (gnome)

[Guido Trentalancia]

Hello Dominick.

On Thu, 2012-06-21 at 20:06 +0200, Dominick Grift wrote:
> 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;
 
@@ -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

> On Thu, 2012-06-21 at 19:58 +0200, Dominick Grift wrote:
> > On Thu, 2012-06-21 at 19:38 +0200, Guido Trentalancia wrote:
> > > Hello Dominick.
> > > 
> > > On Thu, 2012-06-21 at 10:41 +0200, Dominick Grift wrote:
> > > > On Wed, 2012-06-20 at 23:03 +0200, Guido Trentalancia wrote:
> > > > > 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 <guido@trentalancia.com>
> > > > > ---
> > > > >  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	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)
> > > > > 
> > > > 
> > > > 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.
> > > 
> > > 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.
> > 
> > > --- 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;
> > >  
> > > @@ -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)

[refpolicy] [PATCH v2]: missing file context for system-tools-backends (gnome)

[Daniel J Walsh]

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

On 06/21/2012 02:41 PM, Guido Trentalancia wrote:
> Hello Dominick.
> 
> On Thu, 2012-06-21 at 20:06 +0200, Dominick Grift wrote:
>> 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;
> 
> @@ -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
> 
>> On Thu, 2012-06-21 at 19:58 +0200, Dominick Grift wrote:
>>> On Thu, 2012-06-21 at 19:38 +0200, Guido Trentalancia wrote:
>>>> Hello Dominick.
>>>> 
>>>> On Thu, 2012-06-21 at 10:41 +0200, Dominick Grift wrote:
>>>>> On Wed, 2012-06-20 at 23:03 +0200, Guido Trentalancia wrote:
>>>>>> 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 <guido@trentalancia.com> --- 
>>>>>> 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
>>>>>> 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)
>>>>>> 
>>>>> 
>>>>> 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.
>>>> 
>>>> 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.
>>> 
>>>> --- 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;
>>>> 
>>>> @@ -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)
> 
> 
> _______________________________________________ refpolicy mailing list 
> refpolicy at oss.tresys.com http://oss.tresys.com/mailman/listinfo/refpolicy
> 


I can't seem to find this package in Fedora 18?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEUEARECAAYFAk/jbacACgkQrlYvE4MpobOSGQCXUFHtI2IWmWhCO6sKB9jKSFj1
rwCgoMwMrORcCIlKiOnNta9vWfQC7Ng=
=ASMb
-----END PGP SIGNATURE-----

[refpolicy] [PATCH]: missing file context for system-tools-backends (gnome)

[Guido Trentalancia]

On Thu, 2012-06-21 at 19:58 +0200, Dominick Grift wrote:
> On Thu, 2012-06-21 at 19:38 +0200, Guido Trentalancia wrote:
> > Hello Dominick.

[cut]

> 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

[refpolicy] [PATCH]: missing file context for system-tools-backends (gnome)

[Dominick Grift]

On Sat, 2012-06-23 at 10:59 +0200, Guido Trentalancia wrote:

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

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.

[refpolicy] [PATCH]: missing file context for system-tools-backends (gnome)

[Guido Trentalancia]

Hello Dominick.

On Sat, 2012-06-23 at 11:12 +0200, Dominick Grift wrote:
> On Sat, 2012-06-23 at 10:59 +0200, Guido Trentalancia wrote:
> 
> > 
> > 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
> > 
> 
> 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.

Yes, that would be much better of course !

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

[refpolicy] [PATCH]: missing file context for system-tools-backends (gnome)

[Dominick Grift]

On Sat, 2012-06-23 at 11:52 +0200, Guido Trentalancia wrote:

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

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


> Regards,
> 
> Guido
> 

[refpolicy] [PATCH]: missing file context for system-tools-backends (gnome)

[Guido Trentalancia]

Hello Dominick.

On Sat, 2012-06-23 at 12:19 +0200, Dominick Grift wrote:
> On Sat, 2012-06-23 at 11:52 +0200, Guido Trentalancia wrote:
> 
> > 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 ?
> 
> 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.

Yes, more or less what I was imagining.

I would need to test it first and then eventually submit another patch
when possible.

It takes just a little bit more but at least we can get rid of the risky
corecmd_* permissions.

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

My involvement at the moment is just as a sort of part-time hobbist and
there is a lot more policy and stuff that I'd like to work on, but
unfortunately work constrains do not always allow me to do that.

So, I bet further involvement with other online resources such as irc is
impossible as the list is already considered as heavy load for me at the
moment !

Consider I am also hitting a bug in libsepol when trying to build the
latest policy, so there is a lot of things to sort out and time is very
scarce...

And in reply to what Daniel added, I think Fedora has its own system
configuration tools (for example the system-config-*), so that's
probably the reason why they decided to drop gnome-system-tools and
system-backends-tools if as you say it is not possible to find them
anymore in the latest repository...

Thanks a lot for your comments though !

Regards,

Guido