From: dominick.grift@gmail.com (Dominick Grift)
Date: Sun, 12 Jan 2014 13:23:54 +0100
Subject: [refpolicy] Transition unconfined users to dpkg_t domain
In-Reply-To: <10071582.tSbv3mLmCQ@russell.coker.com.au>
References: <20140109171932.2c48b131@soldur.bigon.be>
	<20140110184638.GA4709@siphos.be>
	<1389381566.20258.43.camel@x220.localdomain>
	<10071582.tSbv3mLmCQ@russell.coker.com.au>
Message-ID: <1389529434.8106.12.camel@x220.localdomain>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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.