From: sds@tycho.nsa.gov (Stephen Smalley)
Date: Fri, 10 Jan 2014 13:40:17 -0500
Subject: [refpolicy] Transition unconfined users to dpkg_t domain
In-Reply-To: <20140110183906.GA4510@siphos.be>
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>
Message-ID: <52D03E91.1000600@tycho.nsa.gov>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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.