Re: httpd_graceful_shutdown makes httpd_can_network_connect mostly mute
On 08/02/2017 09:01 PM, Dominick Grift wrote:
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.
I had a discussion with apache maintainer in Fedora and he confirmed
that this boolean is no longer needed in Fedora 27 or higher. Adding him
to CC.
I see that in refpolicy, default value of httpd_graceful_shutdown is
off, so we need to fix it only in Fedora distro policy. I'll prepare the
patch.
Lukas.
--
Lukas Vrabec
Software Engineer, Security Technologies
Red Hat, Inc.
Re: httpd_graceful_shutdown makes httpd_can_network_connect mostly mute
On 08/02/2017 08:59 PM, 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?
Same here, I cannot reproduce it or evoke any AVC using apachectl
command. I'm using httpd-2.4.27-12.fc28.x86_64. I'll contact apache
developers but I believe we can switch default value of boolean
httpd_graceful_shutdown to OFF.
Lukas.
--
Lukas Vrabec
Software Engineer, Security Technologies
Red Hat, Inc.
Re: httpd_graceful_shutdown makes httpd_can_network_connect mostly mute
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
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
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
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
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
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...
