m.roth@xxxxxxxxx writes:
> ---------------------------- Original Message ----------------------------
> Subject: Re: [HEADS UP] Default value of SELinux boolean
> httpd_graceful_shutdown will changed.
> From: "Lukas Vrabec" <lvrabec@xxxxxxxxxx>
> Date: Fri, September 29, 2017 10:26
> To: devel@xxxxxxxxxxxxxxxxxxxxxxx
> "Selinux List at Fedora Project" <selinux@xxxxxxxxxxxxxxxxxxxxxxx>
> --------------------------------------------------------------------------
>
> On 09/29/2017 03:57 PM, Alexander Bokovoy wrote:
>> On pe, 29 syys 2017, Lukas Vrabec wrote:
>>> I'm planning change the default value of httpd_graceful_shutdown
>>> boolean in Fedora Rawhide because of improving SELinux configuration.
>>> Rawhide builds with this change will be available in ~5 days.
>>>
>>> Together with Dan Walsh, we agreed on that httpd_graceful_shutdown
>>> boolean should be by default turned off. This boolean allows HTTPD to
>>> connect to port 80 for graceful shutdown, but it's breaking the
>>> functionality of another boolean called: httpd_can_network_connect.
>>> This boolean allows HTTPD scripts and modules to connect to the
>>> network using TCP and it's turned off by default.
>>>
>>> Turning this boolean off can cause some troubles, on web-servers where
>>> processes with httpd_t SELinux domain connecting to tcp ports: 80, 81,
>>> 443, 488, 8008, 8009, 8443, 9000
>>>
>>> If you would like to turn in on again, use semanage command:
>>> # semanage boolean -m --on httpd_graceful_shutdown
>> In FreeIPA we have httpd_can_network_connect enabled. I just checked a F26
>> system and I have both booleans enabled.
>>
>> # getsebool -a|egrep 'httpd_graceful_shutdown|httpd_can_network_connect '
>> httpd_can_network_connect --> on
>> httpd_graceful_shutdown --> on
>>
>> So I'm a bit confused: disabling httpd_graceful_shutdown will have or
>> wouldn't have an effect on httpd_can_network_connect being enabled?
>>
>
> httpd_graceful_shutdown is subset of httpd_can_network_connect.
>
> Turning on httpd_graceful_shutdown you allow httpd_t domain connecting
> just to ports labeled as httpd_port_t.
> Turning on httpd_can_network_connect you allow httpd_t domain connecting
> to all ports from SELinux POV.
>
> Right now, we ship selinux-policy with httpd_graceful_shutdown turned on
> and httpd_can_network_connect turned off. But it's confusing for users
> because they have httpd_can_connect turned off but httpd_t domain can
> still connect co http_port_t ports becuase of httpd_gracefull_shudown.
I would think it´s confusing because the names of these booleans do not
indicate their purpose very well.
I didn´t question what httpd_can_network_connect is supposed to mean,
and I wasn´t aware that there is a distinction between ports. I also
didn´t know that an httpd would require to connect to ports it genuinely
connects to to serve its purpose just to shut down itself. How does
that make sense, and who would want to prevent their httpd from shutting
down gracefully? Since httpd usually connects to the network to be
useful, I wouldn´t expect that httpd_graceful_shutdown has anything to
do with allowing it to connect to some ports.
So unless you do not want to use any of the standard ports for http,
httpd_graceful_shutdown would be enabled unless this boolean
particularly refers to connecting to the standard ports *only* during
shutdown while httpd_can_network_connect does *not* apply during
shutdown. I somehow doubt that this is so.
Perhaps it would better to rename these booleans like
httpd_can_connect_default_ports
httpd_can_connect_all_ports
and have a third one like
httpd_can_connect_sql_ports.
That last one would have to somehow take encrypted connections into
account.
You´d still have to make a general design decision whether a permission
that is broader than another one overrides the narrower permission. I
would vote for broader permissions to always override narrower ones and
to issue a warning when someone sets a permission which overrides any
that are narrower. In case you want to do it the other way round,
always give a warning when a narrower permission is enabled but remains
defeated by a broader one.
Not doing that requires users to figure out the effects of permissions
by themselves. How are they supposed to do that?
That must already have been thought about. What is the general decision
here, and the reasoning behind it?
Is there some query program that tells us in more detail what a
particular boolean means?
How would a user --- and probably most of them are having a hard time
already to get around selinux when it gets into their way yet again ---
ever figure out what these booleans mean other than by making
assumptions based on how they are called, and by experimenting?
I´m always tempted to turn selinux off because it´s ridiculously
difficult to figure out what you need to do to be able to do what you
need. I might have to turn it off even because I can´t have a samba
share that is also accessible by httpd and don´t have the time to figure
out how to get that with selinux enabled. It seems to involve
developing my own object types and a special policy and whatnot, and
that might conflict with what´s already there, so it isn´t feasible. And
this is only a very simple case which probably occurs quite often.
--
"Didn't work" is an error.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
