From: guido@trentalancia.com (Guido Trentalancia) Date: Thu, 21 Jun 2012 20:27:53 +0200 Subject: [refpolicy] [PATCH]: missing file context for system-tools-backends (gnome) In-Reply-To: <1340301537.9690.45.camel@x220.mydomain.internal> References: <1340226181.23287.2.camel@vortex> <1340268079.9690.35.camel@x220.mydomain.internal> <1340300284.2992.9.camel@vortex> <1340301537.9690.45.camel@x220.mydomain.internal> Message-ID: <1340303273.2992.30.camel@vortex> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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 > > > > --- > > > > 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 > > # > > > > +## > > +##

> > +## Enable support for system-tools-backends. > > +##

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