From: sven.vermeulen@siphos.be (Sven Vermeulen)
Date: Fri, 10 Jan 2014 19:46:38 +0100
Subject: [refpolicy] Transition unconfined users to dpkg_t domain
In-Reply-To: <52D03E91.1000600@tycho.nsa.gov>
References: <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: <20140110184638.GA4709@siphos.be>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Fri, Jan 10, 2014 at 01:40:17PM -0500, Stephen Smalley wrote:
> >> 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.

The other case being extending the rights of those confined domains more and
more to suit the expectations of the end user? 

The set of changes you're referring to is not never-ending, and they're
currently definitely not transparent. The amount of different approaches
taken by SELinux-aware applications is staggering and often requires
distribution SELinux maintainers to dive into the code to find out why an
application breaks in a certain way.

It would be beneficial if there was a common, documented approach on how to
deal with SELinux if SELinux-awareness is necessary.

Policy-development wise, we are still lacking enough directions (principles)
to continue to work on the policies. Right now, the community that works on
the policies (through the reference policy project) is close enough and has
sufficient discussions on all changes, but as SELinux gets more and more
used, I am expecting that the workload will increase and the number of
decisions to be taken with it.

And how to deal with unconfined domains trying to run an application is
definitely one of them.

Wkr,
	Sven Vermeulen