From: sven.vermeulen@siphos.be (Sven Vermeulen)
Date: Fri, 10 Jan 2014 19:39:06 +0100
Subject: [refpolicy] Transition unconfined users to dpkg_t domain
In-Reply-To: <52D02FC4.7030109@tycho.nsa.gov>
References: <20140109165738.77a1d0a8@soldur.bigon.be>
	<1389283972.15747.21.camel@x220.localdomain>
	<20140109171932.2c48b131@soldur.bigon.be>
	<1389285402.15747.31.camel@x220.localdomain>
	<52CF05E6.7070904@redhat.com> <52CF0743.4050305@tycho.nsa.gov>
	<20140110124748.3d3bac9c@soldur.bigon.be>
	<52D008E5.2010400@tycho.nsa.gov>
	<20140110182732.3c6f298a@soldur.bigon.be>
	<52D02FC4.7030109@tycho.nsa.gov>
Message-ID: <20140110183906.GA4510@siphos.be>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Fri, Jan 10, 2014 at 12:37:08PM -0500, Stephen Smalley wrote:
> > About my initial issue with dpkg exiting if it cannot transition to
> > "dpkg_script_t" from unconfined users. How do you think this should be
> > solved? People doesn't like the transition of unconfined domains to
> > confined ones (I agree with this), so you think this should be fixed in
> > the code (setexecfilecon() or dpkg) or this could achieved in an other
> > way in the policy?
> 
> What's wrong with transitioning from unconfined to confined?  Going from
> more-privileged to less-privileged is the common (and safe) case, e.g.
> init -> daemon, login -> user, etc.  It is confined -> unconfined
> transitions that are unsafe.

There is nothing "wrong" with it - it's a design choice of the policy. But I
believe it is confusing for end users. They expect that, if they are running
in an unconfined context, that all actions they invoke (and which aren't
about restarting network facing daemons of course) are unconfined.

If they call rpm or another package manager, and that package manager
suddenly runs in a restricted confined domain, then they might get denials
they do not expect. After all, these are actions they are triggering that
are suddenly denied.

I'm not saying it is simple to implement this principle in practice. It
requires both sufficient work on the policies (for instance, unconfined
domains should have the right file transitions that are otherwise only
assigned to the application domains) and SELinux-aware applications.

Such applications should not only take into account the "permissive" mode
(cfr Dan's blog post on this) but also consult what the target domain should
be when a transition is requested. For instance, Portage wants to transition
to a sandbox domain (which is configured in a /etc/selinux file) but might
be even better suited if it would check what domain transition to perform,
similar to how cron daemons often work.

Wkr,
	Sven Vermeulen