[refpolicy] Transition unconfined users to dpkg_t domain

Stephen Smalley sds at tycho.nsa.gov
Fri Jan 10 13:40:17 EST 2014

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

More information about the refpolicy mailing list