On Wed, 2017-08-16 at 12:10 -0400, Stephen John Smoogen wrote: > On 16 August 2017 at 05:44, Tomas Mraz <tmraz@xxxxxxxxxx> wrote: > > > On 08/16/2017 11:37 AM, Michal Sekletar wrote: > > > On Tue, Aug 15, 2017 at 1:58 PM, Jakub Jelen <jjelen@xxxxxxxxxx> > > > wrote: > > > > > > > > > > > So can we discuss it now once more without the affiliation to > > > > systemd? > > > > The fact is that we still do not have any other replacement > > > > except > > > > firewalls. But do we need one? > > > > > > > > > > IIRC, in the past discussion there was quite a lot of people > > > arguing > > > that we actually need one. I personally don't think we as a > > > distribution need a drop-in replacement. However, what we > > > possibly > > > need, is a migration path for already deployed systems using > > > tcp_wrappers. Just dropping tcp_wrappers and potentially leaving > > > deployed services completely open would very irresponsible. > > > > > > Also we should consider an impact this change will have on our > > > downstreams focusing on enterprise use-cases (CentOS, RHEL). I > > > recon > > > that "splash damage" potentially caused by this change will be > > > bigger > > > there than in Fedora itself. > > > > On the other hand shipping downstream openssh patch adding this > > support > > when there is already similar functionality present in upstream via > > the > > Match directive in sshd_config is something I would definitely not > > vote > > for. > > > > The main purpose of tcp_wrappers is to allow a 'live' control > mechanism to > an op level person/program who may not be able to change > configuration > files without going through change control systems or restart > services (for > similar reasons). > > In various places, changing a startup/shutdown program requires going > through all kinds of extra hassles. So having a layer where the > 'local' > admin can quickly 'stop' some resource usage is required. The > tcp_wrappers > was the mechanism to do this. This meant that openssh/postfix/etc did > not > need to be restarted to get the new ips to allow or disallow. A > program > could go through logs and add/remove hosts to a file without altering > other > files and thus could be apparmor/selinux policy limited for further > protections. > > If there is a way to have systemd read from a 'central' file to > allow/deny > ips without requiring a systemctl reload/restart of all the services > that > would be useful to know and would be the way to call it a > 'replacement' of > the original functionality. Then any .service file could just say it > is > looking at that file for appropriate matches and those that don't > need it > don't. AFAIK, that was the feature that was removed from systemd in 2014. It can not work for services (they handle the connections on their own), but it can simply work with systemd sockets (and instanced services). And the same way it worked for sockets, it will work in future using tcpd by replacing ExecStart=-/usr/sbin/sshd -i $OPTIONS with ExecStart=@-/usr/sbin/tcpd /usr/sbin/sshd -i $OPTIONS in /etc/systemd/system/sshd@.service (for SSHD example). Source [1]. It needs some tweaks to SELinux policy (I am having a look into that), but there is a way for these who need it. Also using sockets will allow you that every service instance is reading a fresh configuration (in SSHD case). [1] https://lists.freedesktop.org/archives/systemd-devel/2014-April/018 793.html Regards, -- Jakub Jelen Software Engineer Security Technologies Red Hat, Inc. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
