raising warning flag on firewalld-default feature

Matthew Miller mattdm at fedoraproject.org
Tue Nov 13 17:21:44 UTC 2012


On Tue, Nov 13, 2012 at 06:03:18PM +0100, Thomas Woerner wrote:
> >I understand that some services work that way. However, I don't think that
> >this is the best design for a firewall service. Is there some way to force
> >the internal state to be recorded?
> >Let's say there is a security fix for the firewall service which needs to be
> >applied. The daemon will need to be reloaded. Is this now not possible?
> Some services work that way? Only some? If you have a security fix,
> you have to restart every service to get the new code.

Correct. Some services save their state immediately to disk when there is a
critical change, and others do so on shutdown.

> Firewalld is not able to save the state for a later start.

Okay. I think it needs to be able to, before it's ready for prime-time.



> >Sorry, this comment lost context: I didn't mean that the timeout
> >implementation was poor. I meant that if the service were dbus activated,
> >it could stay running if it continued to have things to do, and exit
> >(maybe after a brief wait) if not.
> The security team asked me not to make firewalld a D-BUS driven
> mechanism, because of security concerns and also because of SELinux.

SELinux and D-Bus can work together.

Can you elaborate on the security concerns?

> Additionally every load of the mechanism could have to load modified
> or removed configuration files. So how should it get to the same
> state then again? How should it react on and reflect configuration
> changes? So it would have to write out everything - the state and
> all configuration files. I am sorry, but this is overkill and a most
> likely a source of big problems.

Any firewall service clearly needs to do these things whether or not it is
D-Bus activated.

Given that, doing it all the time is not significantly more work, and
actually likely to be more robust, because the code will be the normal path
and exercised all the time, not a special case.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm at fedoraproject.org>


More information about the devel mailing list