[refpolicy] Transition unconfined users to dpkg_t domain

Dominick Grift dominick.grift at gmail.com
Sun Jan 12 07:23:54 EST 2014


On Sun, 2014-01-12 at 11:59 +1100, Russell Coker wrote:
> On Fri, 10 Jan 2014 20:19:26 Dominick Grift wrote:
> > > The set of changes you're referring to is not never-ending, and they're
> > > currently definitely not transparent.
> > 
> > I agree, Whether you transition to RPM domain or not, The files will
> > still be created with the right context because RPM uses libselinux for
> > that regardless. There is no reason to domain transition to
> > rpm_t/rpm_script_t because that domain is as unconfined as unconfined_t.
> 
> If daemons are launched by the package management system then transitioning 
> from a domain like rpm_script_t or dpkg_script_t might be better than 
> transitioning from the domain used by the sysadmin (unconfined_t or sysadm_t).
> 
> I have the impression that Red Hat is going all systemd, so all daemons should 
> be launched from it instead of being launched directly.  In Debian the init 
> issue is still being debated, but I guess we could just make systemd the 
> primary target and not worry too much if things don't work as well on other 
> systems.
> 

I recently submitted a patch that makes DIRECT_INITRC apply to
unconfined_t as it does sysadm_t

So with the init daemons that use shell init scripts you could tune the
behaviour. If set to on, then both sysadm_r:sysadm_t as well as
unconfined_r:unconfined_t will role/domain transition on executing
"init_script_file". If its off then both unconfined_t as well as
sysadm_t run the scripts in their own domain (and then they can use
run_init is they want to implicitly run a init script file on behalf of
the system.

package managers scripts do all kind of weird stuff. Consider the
following (where even running a package manager in its own domain will
not help): a package (re)starts a daemon but not via its init script.

Then you might end up with a daemon running in the package managers
script domain (which obviously is also very permissive due to the nature
of the domain).

I still stand by my statements. If selinux aware apps like package
managers are designed properly, then running such an app without a
domain transition should not require any change to its code.

We done something similar with cron, where one can conditionally run
jobs in the user domain or in a dedicated cronjob_t domain.

The nature of package managers is that they just need a lot of
permissions. I do not see how SELinux can enforce much integrity there.
It's more of a trust thing in my view.

Unconfined_t and i guess sysadm_t need to also be able to install stuff
(consider installing apps from source (make install))

I am not saying that i think we can drop the package managers domains, i
am just saying the i think that it is more consistent to at least for
unconfined_t run package managers without a domain transition.





More information about the refpolicy mailing list