m.roth at 5-cent.us writes: > ---------------------------- Original Message ---------------------------- > Subject: Re: [HEADS UP] Default value of SELinux boolean > httpd_graceful_shutdown will changed. > From: "Lukas Vrabec" <lvrabec at redhat.com> > Date: Fri, September 29, 2017 10:26 > To: devel at lists.fedoraproject.org > "Selinux List at Fedora Project" <selinux at lists.fedoraproject.org> > -------------------------------------------------------------------------- > > 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.