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

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