From: sven.vermeulen@siphos.be (Sven Vermeulen)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] Transition unconfined users to dpkg_t domain
Date: Fri, 10 Jan 2014 19:39:06 +0100 [thread overview]
Message-ID: <20140110183906.GA4510@siphos.be> (raw)
In-Reply-To: <52D02FC4.7030109@tycho.nsa.gov>
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
next prev parent reply other threads:[~2014-01-10 18:39 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-07 12:29 [refpolicy] Transition unconfined users to dpkg_t domain Laurent Bigonville
[not found] ` <CAPzO=NxbnkP-M-GJhDxW4w=5q7Q6xWgG=m3J1p09ETTs-HuzNw@mail.gmail.com>
[not found] ` <20140107181207.13f8826d@soldur.bigon.be>
2014-01-09 12:24 ` Laurent Bigonville
2014-01-09 13:46 ` Dominick Grift
2014-01-09 15:57 ` Laurent Bigonville
2014-01-09 16:12 ` Dominick Grift
2014-01-09 16:19 ` Laurent Bigonville
2014-01-09 16:36 ` Dominick Grift
2014-01-09 20:26 ` Daniel J Walsh
2014-01-09 20:32 ` Stephen Smalley
2014-01-10 11:47 ` Laurent Bigonville
2014-01-10 13:49 ` Daniel J Walsh
2014-01-10 14:51 ` Stephen Smalley
2014-01-10 14:59 ` Daniel J Walsh
2014-01-10 17:27 ` Laurent Bigonville
2014-01-10 17:37 ` Stephen Smalley
2014-01-10 18:39 ` Sven Vermeulen [this message]
2014-01-10 18:40 ` Stephen Smalley
2014-01-10 18:46 ` Sven Vermeulen
2014-01-10 19:19 ` Dominick Grift
2014-01-12 0:59 ` Russell Coker
2014-01-12 12:23 ` Dominick Grift
2014-01-13 12:35 ` Russell Coker
2014-01-10 18:52 ` Dominick Grift
2014-01-10 19:58 ` Stephen Smalley
2014-01-12 1:04 ` Russell Coker
2014-01-12 12:25 ` Dominick Grift
2014-01-12 12:20 ` Laurent Bigonville
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140110183906.GA4510@siphos.be \
--to=sven.vermeulen@siphos.be \
--cc=refpolicy@oss.tresys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.