Re: tcp_wrappers deprecation

[James Hogarth]

On 24 August 2017 at 10:33, Peter Robinson  wrote:

> > On Tue, 2017-08-15 at 13:58 +0200, Jakub Jelen wrote:
> >> Hello Fedora devels and users,
> >>
> >> more than three years ago, the same topic started discussion if we
> >> want
> >> this package in Fedora or not and how [1]. The discussion resulted
> >> mostly in flames and in the removal of the dependency on tcp_wrappers
> >> from systemd. But it was quite agreed that it is considered as a
> >> security layer for some users, if they use it correctly, or something
> >> that is or should be replaced by firewalls.
> >>
> >> 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?
> >>
> >> The complete removal of the package is probably not a wise step, even
> >> though we can not find tcp_wrappers in recent SuSE anymore [2]. It is
> >> still available in Arch [3] without other tools depending on it. To
> >> be
> >> fair, Debian [4] is still building tools (for example openssh) with a
> >> build-time support for it.
> >>
> >> My primary concern is OpenSSH, which upstream dropped support for
> >> tcp_wrappers three years ago (late 2014) [5] and since then we are
> >> maintaining one more downstream patch. But this effort should be
> >> coordinated among other components to simplify the transition for
> >> users
> >> who insist on using it (using tcpd).
> >>
> >> Removing the dependency will also allow us to trim the default
> >> install for few more Kb.
> >>
> >> If there will be no significant drawbacks, I will progress with
> >> filling
> >> a system wide change for Fedora 28 and I will pull the maintainers of
> >> other tolls using libwrap into the round and discussion.
> >
> > Hello,
> > In Fedora 26, there is over 50 packages using tcp_wrappers as a build-
> > time dependency:
> >
> >
> > Since I'm listed twice in there...
> >
> > With my packages and the situation with build time options I take the
> > position of enable as much as possible since our users don't get to pick
> > their compilation options.
> >
> > However tcp_wrappers is a legacy thing that no longer belongs in today's
> > world.
> >
> > I have no objection to a flag day in F28 development and dropping the
> build
> > option at some point, preferably before the thing that is no longer an
> alpha
> > ;) ... ie way before beta.
>
> With F-27 now branched off this can happen in F-28/rawhide now
> ___
>
>
Indeed ... it's a great time to do so ... but let's carry it out under the
auspices of a System Wide Change for F28 :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: tcp_wrappers deprecation

[Peter Robinson]

> On Tue, 2017-08-15 at 13:58 +0200, Jakub Jelen wrote:
>> Hello Fedora devels and users,
>>
>> more than three years ago, the same topic started discussion if we
>> want
>> this package in Fedora or not and how [1]. The discussion resulted
>> mostly in flames and in the removal of the dependency on tcp_wrappers
>> from systemd. But it was quite agreed that it is considered as a
>> security layer for some users, if they use it correctly, or something
>> that is or should be replaced by firewalls.
>>
>> 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?
>>
>> The complete removal of the package is probably not a wise step, even
>> though we can not find tcp_wrappers in recent SuSE anymore [2]. It is
>> still available in Arch [3] without other tools depending on it. To
>> be
>> fair, Debian [4] is still building tools (for example openssh) with a
>> build-time support for it.
>>
>> My primary concern is OpenSSH, which upstream dropped support for
>> tcp_wrappers three years ago (late 2014) [5] and since then we are
>> maintaining one more downstream patch. But this effort should be
>> coordinated among other components to simplify the transition for
>> users
>> who insist on using it (using tcpd).
>>
>> Removing the dependency will also allow us to trim the default
>> install for few more Kb.
>>
>> If there will be no significant drawbacks, I will progress with
>> filling
>> a system wide change for Fedora 28 and I will pull the maintainers of
>> other tolls using libwrap into the round and discussion.
>
> Hello,
> In Fedora 26, there is over 50 packages using tcp_wrappers as a build-
> time dependency:
>
>
> Since I'm listed twice in there...
>
> With my packages and the situation with build time options I take the
> position of enable as much as possible since our users don't get to pick
> their compilation options.
>
> However tcp_wrappers is a legacy thing that no longer belongs in today's
> world.
>
> I have no objection to a flag day in F28 development and dropping the build
> option at some point, preferably before the thing that is no longer an alpha
> ;) ... ie way before beta.

With F-27 now branched off this can happen in F-28/rawhide now
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: tcp_wrappers deprecation

[James Hogarth]

On 18 Aug 2017 4:42 pm, "Jakub Jelen"  wrote:

On Tue, 2017-08-15 at 13:58 +0200, Jakub Jelen wrote:
> Hello Fedora devels and users,
>
> more than three years ago, the same topic started discussion if we
> want
> this package in Fedora or not and how [1]. The discussion resulted
> mostly in flames and in the removal of the dependency on tcp_wrappers
> from systemd. But it was quite agreed that it is considered as a
> security layer for some users, if they use it correctly, or something
> that is or should be replaced by firewalls.
>
> 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?
>
> The complete removal of the package is probably not a wise step, even
> though we can not find tcp_wrappers in recent SuSE anymore [2]. It is
> still available in Arch [3] without other tools depending on it. To
> be
> fair, Debian [4] is still building tools (for example openssh) with a
> build-time support for it.
>
> My primary concern is OpenSSH, which upstream dropped support for
> tcp_wrappers three years ago (late 2014) [5] and since then we are
> maintaining one more downstream patch. But this effort should be
> coordinated among other components to simplify the transition for
> users
> who insist on using it (using tcpd).
>
> Removing the dependency will also allow us to trim the default
> install for few more Kb.
>
> If there will be no significant drawbacks, I will progress with
> filling
> a system wide change for Fedora 28 and I will pull the maintainers of
> other tolls using libwrap into the round and discussion.

Hello,
In Fedora 26, there is over 50 packages using tcp_wrappers as a build-
time dependency:


Since I'm listed twice in there...

With my packages and the situation with build time options I take the
position of enable as much as possible since our users don't get to pick
their compilation options.

However tcp_wrappers is a legacy thing that no longer belongs in today's
world.

I have no objection to a flag day in F28 development and dropping the build
option at some point, preferably before the thing that is no longer an
alpha ;) ... ie way before beta.

As for downstream ... well we're Fedora. If Red Hat want it still in RHEL8
that's up to them and they can maintain the downstream patches in their
distro still.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: tcp_wrappers deprecation

[Alexander Bokovoy]

On ma, 21 elo 2017, Jason L Tibbitts III wrote:

"JJ" == Jakub Jelen  writes:


JJ> The denyhosts got last update also 10 years ago [2] and we already
JJ> have quite much 2 alternatives that can do the same using firewalls,
JJ> so it might be also a time to go for denyhosts. Or not, but clearly
JJ> document that OpenSSH will not be using hosts.deny anymore.

The last denyhosts release was not much over two years ago, actually.
https://github.com/denyhosts/denyhosts

I am nominally active with denyhosts upstream, though I just don't have
the time to do the things I really want to do (like fix my support for
the systemd journal or get firewalld support merged).

JJ> That would be great if you could review the dependencies if it is
JJ> used and drop the bogus dependencies.

I can verify that the dependencies are real.  There's nothing bogus
about them; the functionality works.  But if course if tcp_wrappers is
really to be retired then they will need to be rebuilt without it.

For example, slapi-nis has tcp_wrappers support built in. It can be
compiled out, all we would lose is NIS plugin not rejecting access to
NIS maps from clients that were defined in hosts.deny. Whether somebody
relies on this functionality or not, I'm not aware -- at least, I
haven't seen any bugs related to that within the FreeIPA NIS integration
context for last six or so years.
--
/ Alexander Bokovoy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: tcp_wrappers deprecation

[Jason L Tibbitts III]

> "JJ" == Jakub Jelen  writes:

JJ> The denyhosts got last update also 10 years ago [2] and we already
JJ> have quite much 2 alternatives that can do the same using firewalls,
JJ> so it might be also a time to go for denyhosts. Or not, but clearly
JJ> document that OpenSSH will not be using hosts.deny anymore.

The last denyhosts release was not much over two years ago, actually.
https://github.com/denyhosts/denyhosts

I am nominally active with denyhosts upstream, though I just don't have
the time to do the things I really want to do (like fix my support for
the systemd journal or get firewalld support merged).

JJ> That would be great if you could review the dependencies if it is
JJ> used and drop the bogus dependencies.

I can verify that the dependencies are real.  There's nothing bogus
about them; the functionality works.  But if course if tcp_wrappers is
really to be retired then they will need to be rebuilt without it.

 - J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: tcp_wrappers deprecation

[Jakub Jelen]

On Fri, 2017-08-18 at 13:15 -0500, Jason L Tibbitts III wrote:
> For the record, denyhosts currently relies upon the tcp_wrappers
> functionality in openssh to function.  While it's possible to make it
> manipulate the firewall as well, the whole situation is kind of a
> mess.
> (Does it talk to firewalld?  What if you're not running firewalld?)

Unfortunately this is not as straightforward as it could be.
Checking how Archlinux does it now, they probably go without denyhosts.
There is a also a tool sshguard [1], which does quite much the same as
fail2ban using configurable backend (firewalld, iptables, ...). 

The denyhosts got last update also 10 years ago [2] and we already have
quite much 2 alternatives that can do the same using firewalls, so it
might be also a time to go for denyhosts. Or not, but clearly document
that OpenSSH will not be using hosts.deny anymore.

> Sadly I know how terrible tcp_wrappers is and so I know it needs to
> go
> away.  It's just unfortunate that there's no replacement for it
> besides
> firewalling, and dealing with the firewall is unfortunately so
> complicated.
> 
> So that's three of my packages that use tcp_wrappers in some way
> (denyhosts, apcupsd and cyrus-imapd) though I suspect two of those
> just
> need the build dependencies dropped.

That would be great if you could review the dependencies if it is used
and drop the bogus dependencies.

[1] https://wiki.archlinux.org/index.php/sshguard
[2] https://sourceforge.net/projects/denyhosts/files/

Thanks,
-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: tcp_wrappers deprecation

[R P Herrold]

On Fri, 18 Aug 2017, Jason L Tibbitts III wrote:

> Sadly I know how terrible tcp_wrappers is and so I know it needs to go
> away.  

just because crows trying to protect their young will 'mob' a 
hawk hunting to feed her young does not make the hawk 
terrible; latest is not always greatest

I found the ranting toward wrappers unconvincing years ago - 
- I remain unconvinced that it is terrible code

> It's just unfortunate that there's no replacement for it besides
> firewalling, and dealing with the firewall is unfortunately so
> complicated.

wrappers will invoke the resolver, and do PTR lookups, and so 
can do:
- hostname based, 
- domain related, and 
- absent DNS information based blocking

I know of no way to do these tasks with the 'firewalld' code

-- Russ herrold
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: tcp_wrappers deprecation

[Jason L Tibbitts III]

For the record, denyhosts currently relies upon the tcp_wrappers
functionality in openssh to function.  While it's possible to make it
manipulate the firewall as well, the whole situation is kind of a mess.
(Does it talk to firewalld?  What if you're not running firewalld?)

Sadly I know how terrible tcp_wrappers is and so I know it needs to go
away.  It's just unfortunate that there's no replacement for it besides
firewalling, and dealing with the firewall is unfortunately so
complicated.

So that's three of my packages that use tcp_wrappers in some way
(denyhosts, apcupsd and cyrus-imapd) though I suspect two of those just
need the build dependencies dropped.

 - J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: tcp_wrappers deprecation

[Dan Horák]

On Fri, 18 Aug 2017 17:42:21 +0200
Jakub Jelen  wrote:

> On Tue, 2017-08-15 at 13:58 +0200, Jakub Jelen wrote:
> > Hello Fedora devels and users,
> > 
> > more than three years ago, the same topic started discussion if we
> > want
> > this package in Fedora or not and how [1]. The discussion resulted
> > mostly in flames and in the removal of the dependency on
> > tcp_wrappers from systemd. But it was quite agreed that it is
> > considered as a security layer for some users, if they use it
> > correctly, or something that is or should be replaced by firewalls.
> > 
> > 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?
> > 
> > The complete removal of the package is probably not a wise step,
> > even though we can not find tcp_wrappers in recent SuSE anymore
> > [2]. It is still available in Arch [3] without other tools
> > depending on it. To be
> > fair, Debian [4] is still building tools (for example openssh) with
> > a build-time support for it.
> > 
> > My primary concern is OpenSSH, which upstream dropped support for
> > tcp_wrappers three years ago (late 2014) [5] and since then we are
> > maintaining one more downstream patch. But this effort should be
> > coordinated among other components to simplify the transition for
> > users
> > who insist on using it (using tcpd).
> > 
> > Removing the dependency will also allow us to trim the default
> > install for few more Kb.
> > 
> > If there will be no significant drawbacks, I will progress with
> > filling
> > a system wide change for Fedora 28 and I will pull the maintainers
> > of other tolls using libwrap into the round and discussion.
> 
> Hello,
> In Fedora 26, there is over 50 packages using tcp_wrappers as a build-
> time dependency:

the query shows packages with run-time (not build-time) dependencies,
in some cases it's an indirect dependency, so the actual list is shorter
 
> $ dnf repoquery --whatrequires 'libwrap.so.0()(64bit)'|grep x86_64
> 389-ds-base-snmp-0:1.3.6.6-2.fc26.x86_64 rmeggins
> aeskulap-0:0.2.2-0.27.beta1.fc26.x86_64  jenslody
> apcupsd-0:3.14.14-5.fc26.x86_64  tibbs
> apcupsd-cgi-0:3.14.14-5.fc26.x86_64
> apcupsd-gui-0:3.14.14-5.fc26.x86_64
> apt-cacher-ng-0:0.9.0-3.fc26.x86_64  kenjiro
> audit-0:2.7.7-1.fc26.x86_64  sgrubb
> bacula-client-0:7.4.7-1.fc26.x86_64  slaanesh
> bacula-director-0:7.4.7-1.fc26.x86_64
> bacula-libs-0:7.4.7-1.fc26.x86_64
> bacula-storage-0:7.4.7-1.fc26.x86_64
> bacula2-client-0:2.4.4-24.fc26.x86_64limb
> conserver-0:8.2.1-3.fc24.x86_64  jkastner
> ctk-devel-0:0.1-0.2.20151015gitbdc8cac.fc26.x86_64   bizdelnick
> ctk-dicom-0:0.1-0.2.20151015gitbdc8cac.fc26.x86_64
> cyrus-imapd-0:3.0.1-7.fc26.x86_64landgraf
> dcmtk-0:3.6.1-4.fc24.x86_64  ignatenkobrain
> dovecot-1:2.2.31-3.fc26.x86_64   mhlavink
> exim-0:4.89-1.fc26.x86_64dwmw2
> flow-tools-0:0.68.5.1-18.fc26.x86_64 stingray
> foghorn-0:0.1.6-12.fc26.x86_64   rohara  
> gsi-openssh-server-0:7.5p1-1.fc26.x86_64 ellert
> libvirt-snmp-0:0.0.3-7.fc24.x86_64   mprivozn
> libyaz-0:5.14.11-6.fc26.x86_64   guidograzioli
> lldpd-0:0.9.7-5.fc26.x86_64  jhogarth
> net-snmp-1:5.7.3-15.fc26.x86_64  jsafrane
> net-snmp-agent-libs-1:5.7.3-15.fc26.x86_64
> nfs-utils-1:2.1.1-5.rc4.fc26.x86_64  steved
> ngircd-0:24-2.fc26.x86_64ixs
> nrpe-0:3.0.1-4.fc26.x86_64   smooge
> nut-0:2.7.4-7.fc26.x86_64mhlavink
> ocserv-0:0.11.8-1.fc26.x86_64nmav
> openhpi-subagent-0:2.3.4-28.fc26.x86_64  sharkcz
> openldap-servers-0:2.4.44-10.fc26.x86_64 mhonek
> opensips-snmpstats-0:2.2.3-1.fc26.x86_64 ivaxer
> openssh-server-0:7.5p1-2.fc26.x86_64 jjelen
> pptpd-0:1.4.0-11.fc26.x86_64 jskarvad
> prelude-manager-0:3.1.0-2.fc26.x86_64totol
> proftpd-0:1.3.6-1.fc26.x86_64itamarjp
> ptpd-0:2.3.1-4.fc24.x86_64   pbrobinson
> pulseaudio-libs-0:10.0-4.fc26.x86_64 lennart
> quagga-0:1.1.1-2.fc26.x86_64 mruprich
> quota-rpc-1:4.03-8.fc26.x86_64   ppisar
> redir-0:2.2.1-16.fc26.x86_64 itamarjp
> rpcbind-0:0.2.4-7.rc2.fc26.x86_64steved
> rwhoisd-0:1.5.9.6-6.fc26.x86_64  ppisar
> sendmail-0:8.15.2-14.fc26.x86_64 jskarvad
> slapi-nis-0:0.56.1-2.fc26.x86_64 abbra
> sslh-0:1.18-2.fc26.x86_64  

Re: tcp_wrappers deprecation

[Jakub Jelen]

On Tue, 2017-08-15 at 13:58 +0200, Jakub Jelen wrote:
> Hello Fedora devels and users,
> 
> more than three years ago, the same topic started discussion if we
> want
> this package in Fedora or not and how [1]. The discussion resulted
> mostly in flames and in the removal of the dependency on tcp_wrappers
> from systemd. But it was quite agreed that it is considered as a
> security layer for some users, if they use it correctly, or something
> that is or should be replaced by firewalls.
> 
> 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?
> 
> The complete removal of the package is probably not a wise step, even
> though we can not find tcp_wrappers in recent SuSE anymore [2]. It is
> still available in Arch [3] without other tools depending on it. To
> be
> fair, Debian [4] is still building tools (for example openssh) with a
> build-time support for it.
> 
> My primary concern is OpenSSH, which upstream dropped support for
> tcp_wrappers three years ago (late 2014) [5] and since then we are
> maintaining one more downstream patch. But this effort should be
> coordinated among other components to simplify the transition for
> users
> who insist on using it (using tcpd).
> 
> Removing the dependency will also allow us to trim the default
> install for few more Kb.
> 
> If there will be no significant drawbacks, I will progress with
> filling
> a system wide change for Fedora 28 and I will pull the maintainers of
> other tolls using libwrap into the round and discussion.

Hello,
In Fedora 26, there is over 50 packages using tcp_wrappers as a build-
time dependency:

$ dnf repoquery --whatrequires 'libwrap.so.0()(64bit)'|grep x86_64
389-ds-base-snmp-0:1.3.6.6-2.fc26.x86_64 rmeggins
aeskulap-0:0.2.2-0.27.beta1.fc26.x86_64  jenslody
apcupsd-0:3.14.14-5.fc26.x86_64  tibbs
apcupsd-cgi-0:3.14.14-5.fc26.x86_64
apcupsd-gui-0:3.14.14-5.fc26.x86_64
apt-cacher-ng-0:0.9.0-3.fc26.x86_64  kenjiro
audit-0:2.7.7-1.fc26.x86_64  sgrubb
bacula-client-0:7.4.7-1.fc26.x86_64  slaanesh
bacula-director-0:7.4.7-1.fc26.x86_64
bacula-libs-0:7.4.7-1.fc26.x86_64
bacula-storage-0:7.4.7-1.fc26.x86_64
bacula2-client-0:2.4.4-24.fc26.x86_64limb
conserver-0:8.2.1-3.fc24.x86_64  jkastner
ctk-devel-0:0.1-0.2.20151015gitbdc8cac.fc26.x86_64   bizdelnick
ctk-dicom-0:0.1-0.2.20151015gitbdc8cac.fc26.x86_64
cyrus-imapd-0:3.0.1-7.fc26.x86_64landgraf
dcmtk-0:3.6.1-4.fc24.x86_64  ignatenkobrain
dovecot-1:2.2.31-3.fc26.x86_64   mhlavink
exim-0:4.89-1.fc26.x86_64dwmw2
flow-tools-0:0.68.5.1-18.fc26.x86_64 stingray
foghorn-0:0.1.6-12.fc26.x86_64   rohara  
gsi-openssh-server-0:7.5p1-1.fc26.x86_64 ellert
libvirt-snmp-0:0.0.3-7.fc24.x86_64   mprivozn
libyaz-0:5.14.11-6.fc26.x86_64   guidograzioli
lldpd-0:0.9.7-5.fc26.x86_64  jhogarth
net-snmp-1:5.7.3-15.fc26.x86_64  jsafrane
net-snmp-agent-libs-1:5.7.3-15.fc26.x86_64
nfs-utils-1:2.1.1-5.rc4.fc26.x86_64  steved
ngircd-0:24-2.fc26.x86_64ixs
nrpe-0:3.0.1-4.fc26.x86_64   smooge
nut-0:2.7.4-7.fc26.x86_64mhlavink
ocserv-0:0.11.8-1.fc26.x86_64nmav
openhpi-subagent-0:2.3.4-28.fc26.x86_64  sharkcz
openldap-servers-0:2.4.44-10.fc26.x86_64 mhonek
opensips-snmpstats-0:2.2.3-1.fc26.x86_64 ivaxer
openssh-server-0:7.5p1-2.fc26.x86_64 jjelen
pptpd-0:1.4.0-11.fc26.x86_64 jskarvad
prelude-manager-0:3.1.0-2.fc26.x86_64totol
proftpd-0:1.3.6-1.fc26.x86_64itamarjp
ptpd-0:2.3.1-4.fc24.x86_64   pbrobinson
pulseaudio-libs-0:10.0-4.fc26.x86_64 lennart
quagga-0:1.1.1-2.fc26.x86_64 mruprich
quota-rpc-1:4.03-8.fc26.x86_64   ppisar
redir-0:2.2.1-16.fc26.x86_64 itamarjp
rpcbind-0:0.2.4-7.rc2.fc26.x86_64steved
rwhoisd-0:1.5.9.6-6.fc26.x86_64  ppisar
sendmail-0:8.15.2-14.fc26.x86_64 jskarvad
slapi-nis-0:0.56.1-2.fc26.x86_64 abbra
sslh-0:1.18-2.fc26.x86_64jhogarth
stunnel-0:5.41-1.fc26.x86_64 tmraz
syslog-ng-0:3.9.1-1.fc26.x86_64  marcusk
tcp_wrappers-devel-0:7.6-85.fc26.x86_64  jjelen
tftp-server-0:5.2-20.fc26.x86_64 jsynacek
up-imapproxy-0:1.2.8-0.7.20130726svn14389.fc24.x86_64 cmadams
uwsgi-router-access-0:2.0.15-1.fc26.x86_64   kad

Re: tcp_wrappers deprecation

[Jakub Jelen]

On Wed, 2017-08-16 at 12:10 -0400, Stephen John Smoogen wrote:
> On 16 August 2017 at 05:44, Tomas Mraz  wrote:
> 
> > On 08/16/2017 11:37 AM, Michal Sekletar wrote:
> > > On Tue, Aug 15, 2017 at 1:58 PM, Jakub Jelen 
> > > 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: tcp_wrappers deprecation

[Stephen John Smoogen]

On 16 August 2017 at 05:44, Tomas Mraz  wrote:

> On 08/16/2017 11:37 AM, Michal Sekletar wrote:
> > On Tue, Aug 15, 2017 at 1:58 PM, Jakub Jelen  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.



>
> Tomas
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: tcp_wrappers deprecation

[Tomas Mraz]

On 08/16/2017 11:37 AM, Michal Sekletar wrote:
> On Tue, Aug 15, 2017 at 1:58 PM, Jakub Jelen  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.

Tomas
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: tcp_wrappers deprecation

[Michal Sekletar]

On Tue, Aug 15, 2017 at 1:58 PM, Jakub Jelen  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.

Michal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org