On Tue, Jul 18, 2017 at 09:17:58AM -0400, Stephen Smalley wrote:
> On Mon, 2017-07-17 at 15:54 -0400, Paul Moore wrote:
> > On Sun, Jul 16, 2017 at 11:15 AM, Jason Zaman <jason@xxxxxxxxxxxxx>
> > wrote:
> > > On Fri, Jul 14, 2017 at 12:46:47PM -0400, Stephen Smalley wrote:
> > > > As systemd ramps up enabling NNP (NoNewPrivileges) for system
> > > > services,
> > > > it is increasingly breaking SELinux domain transitions for those
> > > > services
> > > > and their descendants. systemd enables NNP not only for services
> > > > whose
> > > > unit files explicitly specify NoNewPrivileges=yes but also for
> > > > services
> > > > whose unit files specify any of the following options in
> > > > combination with
> > > > running without CAP_SYS_ADMIN (e.g. specifying User= or a
> > > > CapabilityBoundingSet= without CAP_SYS_ADMIN): SystemCallFilter=,
> > > > SystemCallArchitectures=, RestrictAddressFamilies=,
> > > > RestrictNamespaces=,
> > > > PrivateDevices=, ProtectKernelTunables=, ProtectKernelModules=,
> > > > MemoryDenyWriteExecute=, or RestrictRealtime= as per the
> > > > systemd.exec(5)
> > > > man page.
> > > >
> > > > The end result is bad for the security of both SELinux-disabled
> > > > and
> > > > SELinux-enabled systems. Packagers have to turn off these
> > > > options in the unit files to preserve SELinux domain
> > > > transitions. For
> > > > users who choose to disable SELinux, this means that they miss
> > > > out on
> > > > at least having the systemd-supported protections. For users who
> > > > keep
> > > > SELinux enabled, they may still be missing out on some
> > > > protections
> > > > because it isn't necessarily guaranteed that the SELinux policy
> > > > for
> > > > that service provides the same protections in all cases.
> > > >
> > > > commit 7b0d0b40cd78 ("selinux: Permit bounded transitions under
> > > > NO_NEW_PRIVS or NOSUID.") allowed bounded transitions under NNP
> > > > in
> > > > order to support limited usage for sandboxing programs. However,
> > > > defining typebounds for all of the affected service domains
> > > > is impractical to implement in policy, since typebounds requires
> > > > us
> > > > to ensure that each domain is allowed everything all of its
> > > > descendant
> > > > domains are allowed, and this has to be repeated for the entire
> > > > chain
> > > > of domain transitions. There is no way to clone all allow rules
> > > > from
> > > > descendants to their ancestors in policy currently, and doing so
> > > > would
> > > > be undesirable even if it were practical, as it requires leaking
> > > > permissions to objects and operations into ancestor domains that
> > > > could
> > > > weaken their own security in order to allow them to the
> > > > descendants
> > > > (e.g. if a descendant requires execmem permission, then so do all
> > > > of
> > > > its ancestors; if a descendant requires execute permission to a
> > > > file,
> > > > then so do all of its ancestors; if a descendant requires read to
> > > > a
> > > > symbolic link or temporary file, then so do all of its
> > > > ancestors...).
> > > > SELinux domains are intentionally not hierarchical / bounded in
> > > > this
> > > > manner normally, and making them so would undermine their
> > > > protections
> > > > and least privilege.
> > > >
> > > > We have long had a similar tension with SELinux transitions and
> > > > nosuid
> > > > mounts, albeit not as severe. Users often have had to choose
> > > > between
> > > > retaining nosuid on a mount and allowing SELinux domain
> > > > transitions on
> > > > files within those mounts. This likewise leads to unfortunate
> > > > tradeoffs
> > > > in security.
> > > >
> > > > Decouple NNP/nosuid from SELinux transitions, so that we don't
> > > > have to
> > > > make a choice between them. Introduce a nnp_nosuid_transition
> > > > policy
> > > > capability that causes the ability to transition under NNP/nosuid
> > > > to
> > > > be based on a nnp_nosuid_transition permission between the old
> > > > and new
> > > > contexts rather than typebounds. Domain transitions can then be
> > > > allowed
> > > > in policy without requiring the parent to be a strict superset of
> > > > all of
> > > > its children.
> > > >
> > > > With this change, systemd unit files can be left unmodified from
> > > > upstream.
> > > > SELinux-disabled and SELinux-enabled users will benefit from
> > > > retaining any
> > > > of the systemd-provided protections. SELinux policy will only
> > > > need to
> > > > be adapted to enable the new policy capability and to allow the
> > > > new permission between domain pairs as appropriate.
> > >
> > > A few things, the name is pretty awkward. my main issue with it is
> > > what
> > > if some other similar kind of thing is added in the future then
> > > we'll
> > > have nnp_nosuid_transition that should also cover it but the name
> > > wont
> > > cover it.
> >
> > Yes, I don't think anyone is in love with the name, but no one
> > offered
> > anything better; see the previous patch posting for some of that
> > discussion. If you have a better suggestion I would love to hear it.
>
> Agreed, although I'm skeptical that there will be any "other similar
> kind of thing" added in the future that we would want to cover under
> the same permission.
>
> >
> > > Why do we want to disallow type-bounds to work even with the
> > > capability?
> > > it seems sensible to me to allow typebounds to transition even in
> > > the
> > > future. If we do then we probably dont need the policycap which
> > > seems
> > > less complicated.
> >
> > The suggestion to continue to support bounded domain transitions
> > seems
> > reasonable to me, although we would need to worry about which check
> > to
> > do first (bounded transition or process:nnp_nosuid_transition), and
> > how to limit the auditing/reporting so admins are confused by the
> > first check failing, yet the transition still taking place. None of
> > these are unsolvable problems, but it will likely need a bit more
> > work.
> >
> > I'm sure Stephen has some thoughts on this as well.
>
> Others (e.g. Dominick) seemed to take the opposite view on the earlier
> RFC discussion, i.e. that we should only check the new permission if
> the capability is enabled. I specifically raised that as a question
> there.
>
> I'm willing to change it to fallback to checking for a bounded type,
> but that will mean two audit messages (I don't think we can just hide
> one of them) when neither is allowed. That said, it is unlikely to
> cause much confusion in practice because users typically only look for
> and pay attention to AVC messages, and anyone using audit2allow will
> just end up allowing the permission, not the bounds.
>
I am not opposed to that either. It might be useful. For example you might want to use type_bounds for containers and nnp_nosuid_transition for systemd services.
This whole situation is already messy anyway with or without this. I just feel sorry for the support departments that need to support this.
> >
> > > also how are we thinking to do this in refpol? only add it
> > > specifically
> > > as needed? or would it be added to the execute_file_perms type
> > > macros?
> > > Although, grep typebounds is nowhere to be found currently in
> > > either
> > > refpol and gentoo's repo.
> >
> > I'm *really* hoping this new permission is only granted where
> > absolutely needed, which I hope should be rather small (see the patch
> > description and the discussion regarding systemd unit files).
>
> Actually, I'm not clear on that. If systemd continues to expand the
> usage of these options in its unit files (which seems likely), then I
> could see this ultimately affecting all service domains and all of
> their descendants. If it was only going to be a handful of domains,
> then the typebounds solution might be more tractable, albeit painful.
>
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
Attachment:
signature.asc
Description: PGP signature
