From: bigon@debian.org (Laurent Bigonville)
Date: Sun, 12 Jan 2014 13:20:26 +0100
Subject: [refpolicy] Transition unconfined users to dpkg_t domain
In-Reply-To: <52D03E91.1000600@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> <20140110183906.GA4510@siphos.be>
	<52D03E91.1000600@tycho.nsa.gov>
Message-ID: <20140112132026.1e7fed44@fornost.bigon.be>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

Le Fri, 10 Jan 2014 13:40:17 -0500,
Stephen Smalley <sds@tycho.nsa.gov> a ?crit :

> On 01/10/2014 01:39 PM, Sven Vermeulen wrote:
> > 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.
> 
> Ok, I don't agree.  That way lies madness - a never-ending set of
> changes to userspace programs to re-implement everything already
> provided transparently through policy domain transitions and file type
> transitions.

OK, I've proposed a patch to the ML so at least dpkg will work in
enforcing mode.

If some rework on how the package manager are handled, I guess it
should be done for all of them.

Cheers,

Laurent Bigonville