httpd_graceful_shutdown makes httpd_can_network_connect mostly mute

[Dominick Grift]

Hi,
I don't know if this a too basic question to ask here, or the proper
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.

[Stephen Smalley]

Hi,
I don't know if this a too basic question to ask here, or the proper
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...

[Stephen Smalley]

Post by Dominick Grift

Hi,
I don't know if this a too basic question to ask here, or the proper
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?

[Dominick Grift]

Post by Stephen Smalley

Post by Dominick Grift

Hi,
I don't know if this a too basic question to ask here, or the proper
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.

[Lukas Vrabec]

Post by Dominick Grift

Post by Stephen Smalley

Post by Dominick Grift

Hi,
I don't know if this a too basic question to ask here, or the proper
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]

Post by Stephen Smalley

Post by Dominick Grift

Hi,
I don't know if this a too basic question to ask here, or the proper
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.

[Dominick Grift]

Post by Dominick Grift

Hi,
I don't know if this a too basic question to ask here, or the proper
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

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