Re: suspicious __GFP_NOMEMALLOC in selinux

[Paul Moore]

On Wed, Aug 2, 2017 at 6:50 AM, Michal Hocko  wrote:
> Hi,
> while doing something completely unrelated to selinux I've noticed a
> really strange __GFP_NOMEMALLOC usage pattern in selinux, especially
> GFP_ATOMIC | __GFP_NOMEMALLOC doesn't make much sense to me. GFP_ATOMIC
> on its own allows to access memory reserves while the later flag tells
> we cannot use memory reserves at all. The primary usecase for
> __GFP_NOMEMALLOC is to override a global PF_MEMALLOC should there be a
> need.
>
> It all leads to fa1aa143ac4a ("selinux: extended permissions for
> ioctls") which doesn't explain this aspect so let me ask. Why is the
> flag used at all? Moreover shouldn't GFP_ATOMIC be actually GFP_NOWAIT.
> What makes this path important to access memory reserves?

[NOTE: added the SELinux list to the CC line, please include that list
when asking SELinux questions]

The GFP_ATOMIC|__GFP_NOMEMALLOC use in SELinux appears to be limited
to security/selinux/avc.c, and digging a bit, I'm guessing commit
fa1aa143ac4a copied the combination from 6290c2c43973 ("selinux: tag
avc cache alloc as non-critical") and the avc_alloc_node() function.

I can't say that I'm an expert at the vm subsystem and the variety of
different GFP_* flags, but your suggestion of moving to GFP_NOWAIT in
security/selinux/avc.c seems reasonable and in keeping with the idea
behind commit 6290c2c43973.

-- 
paul moore
security @ redhat

Re: [PATCH v4] selinux: Generalize support for NNP/nosuid SELinux domain transitions

[Paul Moore]

On Mon, Jul 31, 2017 at 10:12 AM, 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 enables transitions under NNP/nosuid to be based on
> a permission (nnp_transition for NNP; nosuid_transition for nosuid)
> between the old and new contexts in addition to the current support
> for bounded transitions.  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 permissions between domain pairs as appropriate.
>
> NB: Allowing nnp_transition between two contexts opens up the potential
> for the old context to subvert the new context by installing seccomp
> filters before the execve.  Allowing nosuid_transition between two contexts
> opens up the potential for a context transition to occur on a file from
> an untrusted filesystem (e.g. removable media or remote filesystem).  Use
> with care.
>
> Signed-off-by: Stephen Smalley 
> ---
> v4 moves both of the new permissions to the new process2 class and
> checks both if both NNP is enabled and the mount is nosuid.
>
>  security/selinux/hooks.c| 47 
> +
>  security/selinux/include/classmap.h |  2 ++
>  security/selinux/include/security.h |  2 ++
>  security/selinux/ss/services.c  |  7 +-
>  4 files changed, 42 insertions(+), 16 deletions(-)

Merged.  Thanks Stephen and everyone else who reviewed and commented
on this patch.

> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 00ad46e..04b8e10 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -2318,6 +2318,7 @@ static int check_nnp_nosuid(const 

Re: httpd_graceful_shutdown makes httpd_can_network_connect mostly mute

[Dominick Grift]

On Wed, Aug 02, 2017 at 06:35:00PM +0200, Dominick Grift wrote:
> On Wed, Aug 02, 2017 at 04:41:00PM +0100, Carlos Rodrigues wrote:
> > Hi,
> > 
> > I don't know if this a too basic question to ask here, or the proper
> > place, but here it goes:
> > 
> > I've been chasing some weird (to me) behavior with the targeted policy
> > on a VM running nginx as a reverse proxy. What happens is that the
> > "httpd_can_network_connect" boolean needs to be enabled for nginx to
> > be able to reach its upstream servers. So far, so good.
> > 
> > However, if the upsteam server happens to be listening in one of the
> > "http_port_t" ports, "httpd_can_network_connect" isn't needed because
> > the "httpd_graceful_shutdown" (default enabled) provides the required
> > allow rule ("name_connect").
> > 
> > This seems strange to me. Is this supposed to be like this? I would
> > expect nginx to be totally unable to establish outbound connections by
> > default.
> > 
> > Best regards,
> > 
> > Carlos Rodrigues
> > 
> > PS: I just spent a few hours on this, wondering why one machine needed
> > "httpd_can_network_connect" and another did not. I guess I've mostly
> > been setting up reverse proxies for "http_port_t" upstreams on CentOS
> > all this time...
> 
> I think the "httpd_graceful_shutdown" is an apache thing (probably for 
> "apachectl graceful-stop"). However I cannot reproduce this behavior with 
> httpd-2.4.27-4.fc27.

Also "httpd_can_network_connect" grants broader network access to httpd


By the way: refpolicy questions should be directed to the refpolicy maillist: 
http://oss.tresys.com/mailman/listinfo/refpolicy

> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
> Dominick Grift



-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift


signature.asc
Description: PGP signature

Re: httpd_graceful_shutdown makes httpd_can_network_connect mostly mute

[Dominick Grift]

On Wed, Aug 02, 2017 at 02:59:34PM -0400, Stephen Smalley wrote:
> On Wed, 2017-08-02 at 18:35 +0200, Dominick Grift wrote:
> > On Wed, Aug 02, 2017 at 04:41:00PM +0100, Carlos Rodrigues wrote:
> > > Hi,
> > > 
> > > I don't know if this a too basic question to ask here, or the
> > > proper
> > > place, but here it goes:
> > > 
> > > I've been chasing some weird (to me) behavior with the targeted
> > > policy
> > > on a VM running nginx as a reverse proxy. What happens is that the
> > > "httpd_can_network_connect" boolean needs to be enabled for nginx
> > > to
> > > be able to reach its upstream servers. So far, so good.
> > > 
> > > However, if the upsteam server happens to be listening in one of
> > > the
> > > "http_port_t" ports, "httpd_can_network_connect" isn't needed
> > > because
> > > the "httpd_graceful_shutdown" (default enabled) provides the
> > > required
> > > allow rule ("name_connect").
> > > 
> > > This seems strange to me. Is this supposed to be like this? I would
> > > expect nginx to be totally unable to establish outbound connections
> > > by
> > > default.
> > > 
> > > Best regards,
> > > 
> > > Carlos Rodrigues
> > > 
> > > PS: I just spent a few hours on this, wondering why one machine
> > > needed
> > > "httpd_can_network_connect" and another did not. I guess I've
> > > mostly
> > > been setting up reverse proxies for "http_port_t" upstreams on
> > > CentOS
> > > all this time...
> > 
> > I think the "httpd_graceful_shutdown" is an apache thing (probably
> > for "apachectl graceful-stop"). However I cannot reproduce this
> > behavior with httpd-2.4.27-4.fc27.
> 
> Hmm...neither can I; seemingly apachectl graceful-stop works without
> requiring this boolean anymore.  So maybe it can be disabled by default
> and removed at some point in Fedora policy?
> 

Would be nice if we would be able to confirm this with the apache maintainer 
before jumping to conclusions.

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift


signature.asc
Description: PGP signature

Re: httpd_graceful_shutdown makes httpd_can_network_connect mostly mute

[Stephen Smalley]

On Wed, 2017-08-02 at 18:35 +0200, Dominick Grift wrote:
> On Wed, Aug 02, 2017 at 04:41:00PM +0100, Carlos Rodrigues wrote:
> > Hi,
> > 
> > I don't know if this a too basic question to ask here, or the
> > proper
> > place, but here it goes:
> > 
> > I've been chasing some weird (to me) behavior with the targeted
> > policy
> > on a VM running nginx as a reverse proxy. What happens is that the
> > "httpd_can_network_connect" boolean needs to be enabled for nginx
> > to
> > be able to reach its upstream servers. So far, so good.
> > 
> > However, if the upsteam server happens to be listening in one of
> > the
> > "http_port_t" ports, "httpd_can_network_connect" isn't needed
> > because
> > the "httpd_graceful_shutdown" (default enabled) provides the
> > required
> > allow rule ("name_connect").
> > 
> > This seems strange to me. Is this supposed to be like this? I would
> > expect nginx to be totally unable to establish outbound connections
> > by
> > default.
> > 
> > Best regards,
> > 
> > Carlos Rodrigues
> > 
> > PS: I just spent a few hours on this, wondering why one machine
> > needed
> > "httpd_can_network_connect" and another did not. I guess I've
> > mostly
> > been setting up reverse proxies for "http_port_t" upstreams on
> > CentOS
> > all this time...
> 
> I think the "httpd_graceful_shutdown" is an apache thing (probably
> for "apachectl graceful-stop"). However I cannot reproduce this
> behavior with httpd-2.4.27-4.fc27.

Hmm...neither can I; seemingly apachectl graceful-stop works without
requiring this boolean anymore.  So maybe it can be disabled by default
and removed at some point in Fedora policy?

Re: httpd_graceful_shutdown makes httpd_can_network_connect mostly mute

[Stephen Smalley]

On Wed, 2017-08-02 at 16:41 +0100, Carlos Rodrigues wrote:
> Hi,
> 
> I don't know if this a too basic question to ask here, or the proper
> place, but here it goes:
> 
> I've been chasing some weird (to me) behavior with the targeted
> policy
> on a VM running nginx as a reverse proxy. What happens is that the
> "httpd_can_network_connect" boolean needs to be enabled for nginx to
> be able to reach its upstream servers. So far, so good.
> 
> However, if the upsteam server happens to be listening in one of the
> "http_port_t" ports, "httpd_can_network_connect" isn't needed because
> the "httpd_graceful_shutdown" (default enabled) provides the required
> allow rule ("name_connect").
> 
> This seems strange to me. Is this supposed to be like this? I would
> expect nginx to be totally unable to establish outbound connections
> by
> default.

In part your question is more appropriate for the Fedora selinux
mailing list since it concerns the particular SELinux policy / boolean
defaults used by Fedora, or perhaps the refpolicy mailing list if the
same is true of upstream refpolicy (I don't know if it is or not). 
However, the underlying kernel issue has come up in the upstream
SELinux kernel issue tracker, see the below link for more context:
https://github.com/SELinuxProject/selinux-kernel/issues/21


> Best regards,
> 
> Carlos Rodrigues
> 
> PS: I just spent a few hours on this, wondering why one machine
> needed
> "httpd_can_network_connect" and another did not. I guess I've mostly
> been setting up reverse proxies for "http_port_t" upstreams on CentOS
> all this time...

Re: httpd_graceful_shutdown makes httpd_can_network_connect mostly mute

[Dominick Grift]

On Wed, Aug 02, 2017 at 04:41:00PM +0100, Carlos Rodrigues wrote:
> Hi,
> 
> I don't know if this a too basic question to ask here, or the proper
> place, but here it goes:
> 
> I've been chasing some weird (to me) behavior with the targeted policy
> on a VM running nginx as a reverse proxy. What happens is that the
> "httpd_can_network_connect" boolean needs to be enabled for nginx to
> be able to reach its upstream servers. So far, so good.
> 
> However, if the upsteam server happens to be listening in one of the
> "http_port_t" ports, "httpd_can_network_connect" isn't needed because
> the "httpd_graceful_shutdown" (default enabled) provides the required
> allow rule ("name_connect").
> 
> This seems strange to me. Is this supposed to be like this? I would
> expect nginx to be totally unable to establish outbound connections by
> default.
> 
> Best regards,
> 
> Carlos Rodrigues
> 
> PS: I just spent a few hours on this, wondering why one machine needed
> "httpd_can_network_connect" and another did not. I guess I've mostly
> been setting up reverse proxies for "http_port_t" upstreams on CentOS
> all this time...

I think the "httpd_graceful_shutdown" is an apache thing (probably for 
"apachectl graceful-stop"). However I cannot reproduce this behavior with 
httpd-2.4.27-4.fc27.

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift


signature.asc
Description: PGP signature

httpd_graceful_shutdown makes httpd_can_network_connect mostly mute

[Carlos Rodrigues]

Hi,

I don't know if this a too basic question to ask here, or the proper
place, but here it goes:

I've been chasing some weird (to me) behavior with the targeted policy
on a VM running nginx as a reverse proxy. What happens is that the
"httpd_can_network_connect" boolean needs to be enabled for nginx to
be able to reach its upstream servers. So far, so good.

However, if the upsteam server happens to be listening in one of the
"http_port_t" ports, "httpd_can_network_connect" isn't needed because
the "httpd_graceful_shutdown" (default enabled) provides the required
allow rule ("name_connect").

This seems strange to me. Is this supposed to be like this? I would
expect nginx to be totally unable to establish outbound connections by
default.

Best regards,

Carlos Rodrigues

PS: I just spent a few hours on this, wondering why one machine needed
"httpd_can_network_connect" and another did not. I guess I've mostly
been setting up reverse proxies for "http_port_t" upstreams on CentOS
all this time...