Re: [arch-general] [arch-dev-public] dropping tcp_wrapper support
I would say the same, but a todo list isn't a to-done list, so keep that in mind. He also pointed out that I got little to no feedback when I asked about this both a year and six months ago, so expectations are pretty low this time around. I'm sure if there were serious objections people would raise them and we could address them.
This is worthy of a news article once we move packages to core only because it could expose some services people didn't previously expect to need to protect.
-Dan
As far as feedback goes, I have used tcp-wrappers a great deal in the past, but not for many years. And the fact that it needs to be so heavily patched suggests that we should not be using it anyway. I agree that we should not have to maintain it anymore, it is an outdated security system that usually gets in the way, and Arch is the only distro I use that turns it on by default. +1
I am an end user who is very unhappy about the removal of this option. I didn't even know dropping tcp_wrappers was under consideration; had I known that I would have spoken up with my vote against removing support. The annoucement suggests that a major reason for dropping support is that it is "confusing" to end users. An easy solution to that is to make a default hosts.allow file that says "ALL : ALL : ALLOW" out of the box. Then those of use wanting to simply restrict access (useful in many scenarios) can change that default as needed. IMO for users who want to use this feature, the burden is on the end user to find which services support tcp wrappers and which don't. A default "allow" policy makes this simple. Surely I'm not the only tcp wrappers user out there. I will sorely miss this option and strongly wish it to remain.
I also use the hosts.allow and hosts.deny files. It's a shame that support for them will be removed. It's easier than iptables. -- vic@demuzere.be :: http://vic.demuzere.be :: PGP: 0x6690CF94 My software never contains bugs, it just develops random features. Sent from my phone, please excuse my brevity. On Jul 16, 2011 7:06 PM, "Peggy Wilkins" <enlil65@gmail.com> wrote:
I am an end user who is very unhappy about the removal of this option. I didn't even know dropping tcp_wrappers was under consideration; had I known that I would have spoken up with my vote against removing support.
The annoucement suggests that a major reason for dropping support is that it is "confusing" to end users. An easy solution to that is to make a default hosts.allow file that says "ALL : ALL : ALLOW" out of the box. Then those of use wanting to simply restrict access (useful in many scenarios) can change that default as needed.
IMO for users who want to use this feature, the burden is on the end user to find which services support tcp wrappers and which don't. A default "allow" policy makes this simple.
Surely I'm not the only tcp wrappers user out there. I will sorely miss this option and strongly wish it to remain.
On 07/16/2011 07:09 PM, Vic Demuzere wrote:
I also use the hosts.allow and hosts.deny files. It's a shame that support for them will be removed. It's easier than iptables.
But it's not the same as iptables. If you're running a server, you would like to use iptables. Anyway if you really want to know what's going on in archlinux development follow the arch-dev-public mailing list. -- Jelle van der Waa
On Saturday 16 July 2011 19:09:47 Vic Demuzere wrote:
I also use the hosts.allow and hosts.deny files. It's a shame that support for them will be removed. It's easier than iptables. I find iptables more easier, and intuitive.
old hosts.allow: sshd: 192. ntfs: 192. iptables: -A INPUT -j REJECT -A INPUT -p tcp -s 192.168.0.0/24 --dport ssh -j ACCEPT -A INPUT -p tcp -s 192.168.0.0/24 --dport nfs -j ACCEPT -A INPUT -p udp -s 192.168.0.0/24 --dport nfs -j ACCEPT -- Andrea
On 16 July 2011 19:22, Andrea Scarpino <andrea@archlinux.org> wrote:
old hosts.allow: sshd: 192. ntfs: 192.
iptables: -A INPUT -j REJECT -A INPUT -p tcp -s 192.168.0.0/24 --dport ssh -j ACCEPT -A INPUT -p tcp -s 192.168.0.0/24 --dport nfs -j ACCEPT -A INPUT -p udp -s 192.168.0.0/24 --dport nfs -j ACCEPT
So, you're saying that those 4 lines are easier than the 2 short ones in hosts.allow? Ah well, I'll have to learn to write iptables scripts then, I suppose. -- vic@demuzere.be :: http://vic.demuzere.be :: PGP: 0x6690CF94 My software never contains bugs, it just develops random features.
On 16 July 2011 19:32, Vic Demuzere <vic@demuzere.be> wrote:
So, you're saying that those 4 lines are easier than the 2 short ones in hosts.allow? Ah well, I'll have to learn to write iptables scripts then, I suppose. I mean its more intuitive in that way, you've more power on what is accepted and what isn't.; e.g. you can apply filters only to one interface.
Why you should write an iptables script? BTW, sorry "-A INPUT -j REJECT" blocks everything then have to be at the last line, and not at first! -- Andrea
Am 16.07.2011 19:41, schrieb Andrea Scarpino:
On 16 July 2011 19:32, Vic Demuzere <vic@demuzere.be> wrote:
So, you're saying that those 4 lines are easier than the 2 short ones in hosts.allow? Ah well, I'll have to learn to write iptables scripts then, I suppose. I mean its more intuitive in that way, you've more power on what is accepted and what isn't.; e.g. you can apply filters only to one interface.
Why you should write an iptables script?
BTW, sorry "-A INPUT -j REJECT" blocks everything then have to be at the last line, and not at first!
You shouldn't do it like this. Look at /etc/iptables/simple_firewall.rules for a simple and non-broken template.
Mind if I try to clear a few things up here? 1. Yes Andrea, your iptables rules will most likely not achieve the desired effect, as placing the REJECT on the top will REJECT traffic before it gets to the ACCEPT. 2. tcp_wrappers is old and logically %100 redundant with a subset of the features of iptables 3. tcp_wrappers is made to operate on a per application layer, this means that the ALL:ALL in allow.deny only blocks applications that are linked with the libwrap librairy. This means that tcp_wrappers denial only protects against a small subset of applications and can create a false sens of security. 4. Fewer and fewer applications make use of tcp_wrappers, this means that updates to packages can open up security holes because of easily unnoticed upstream changes. A good example of this is when vsftpd dropped default support for tcp_wrappers a few years ago and an update could transparently remove the security layer. 5. tcp_wrappers is a slow solution, it creates many checks for every application connection which iptables does inside kernel space in a fraction of the time. 6. tcp_wrappers was made to be (and still is) a discretionary access system (DAC) back in the 80s before OS level firewalls were readily available. DAC security systems logically unwise to trust and are outdated, reflecting the days of the "safe internet". In the end, I tell people that using tcp_wrappers is unnecessary and unwise, iptables is VERY powerful, and once you understand how rules are constructed and parsed it is an easy and manageable solution. Thanks to the Arch devs for taking this out, this was the right move and I will argue that it has made Arch more secure by not supporting outdated security constructs. -Thomas S Hatch
On Sat, Jul 16, 2011 at 1:42 PM, Thomas S Hatch <thatch45@gmail.com> wrote:
In the end, I tell people that using tcp_wrappers is unnecessary and unwise, iptables is VERY powerful, and once you understand how rules are constructed and parsed it is an easy and manageable solution.
I have nothing to say against iptables and other full firewall solutions. However, for my part running a number of desktops for other people at work with only sshd as a service, tcp wrappers plus denyhosts (plus disabling password authentication for good measure) already does exactly what I want. Performance doesn't enter into this issue for us, we have so many spare CPU cycles it's comical. Everyone doesn't have the same circusmstances and needs. I just would like this option to continue because I'm using it now and I find it useful and it meets my immediate needs. I also don't need my time at work diverted into a sudden project to write firewall rules that work for every desktop.
Thanks to the Arch devs for taking this out, this was the right move and I will argue that it has made Arch more secure by not supporting outdated security constructs.
I view it as taking away my freedom to choose to run what I want in the simplest possible way. This is a major change. A large part of the reason I chose Arch is because it is straightforward to configure, hence doesn't require a lot of my time (which is properly spent running servers, not desktops) -- an easy way to get Linux on the desktop for our site which is otherwise all Windows desktops. I already know the limitations of my choice (and I use full firewalls in other situations). Surely there is a good compromise possible...
On 07/16/2011 09:51 PM, Peggy Wilkins wrote:
On Sat, Jul 16, 2011 at 1:42 PM, Thomas S Hatch<thatch45@gmail.com> wrote:
In the end, I tell people that using tcp_wrappers is unnecessary and unwise, iptables is VERY powerful, and once you understand how rules are constructed and parsed it is an easy and manageable solution. I have nothing to say against iptables and other full firewall solutions. However, for my part running a number of desktops for other people at work with only sshd as a service, tcp wrappers plus denyhosts (plus disabling password authentication for good measure) already does exactly what I want. Performance doesn't enter into this issue for us, we have so many spare CPU cycles it's comical.
Thanks to the Arch devs for taking this out, this was the right move and I will argue that it has made Arch more secure by not supporting outdated security constructs. I view it as taking away my freedom to choose to run what I want in
Everyone doesn't have the same circusmstances and needs. I just would like this option to continue because I'm using it now and I find it useful and it meets my immediate needs. I also don't need my time at work diverted into a sudden project to write firewall rules that work for every desktop. You're better of blocking unwanted attempts at ssh with iptables or use sshgaurd. Or you could try http://smarden.org/ipsvd/ the simplest possible way. This is a major change. A large part of the reason I chose Arch is because it is straightforward to configure, hence doesn't require a lot of my time (which is properly spent running servers, not desktops) -- an easy way to get Linux on the desktop for our site which is otherwise all Windows desktops. I already know the limitations of my choice (and I use full firewalls in other situations).
Surely there is a good compromise possible... There
-- Jelle van der Waa
Am 16.07.2011 21:51, schrieb Peggy Wilkins:
I have nothing to say against iptables and other full firewall solutions. However, for my part running a number of desktops for other people at work with only sshd as a service, tcp wrappers plus denyhosts (plus disabling password authentication for good measure) already does exactly what I want. Performance doesn't enter into this issue for us, we have so many spare CPU cycles it's comical.
If you don't enable password authentication, restricting access to the ssh server on a per-host basis is completely unnecessary. Anyway, sshd can be configured to deny connections depending on the host, you don't need tcp_wrappers for that. It would require actually reading a manpage though.
On Sat, Jul 16, 2011 at 3:58 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Anyway, sshd can be configured to deny connections depending on the host, you don't need tcp_wrappers for that.
The cost of that solution is requiring sshd restart every time one wanted to modify access. Not the end of the world though it's susceptible to human error if you forget to do it.
On Sat, Jul 16, 2011 at 8:42 PM, Thomas S Hatch <thatch45@gmail.com> wrote:
Mind if I try to clear a few things up here?
Thanks for the very understandable explanation! Cheers, Tom
On Sat, Jul 16, 2011 at 7:32 PM, Vic Demuzere <vic@demuzere.be> wrote:
On 16 July 2011 19:22, Andrea Scarpino <andrea@archlinux.org> wrote:
old hosts.allow: sshd: 192. ntfs: 192.
iptables: -A INPUT -j REJECT -A INPUT -p tcp -s 192.168.0.0/24 --dport ssh -j ACCEPT -A INPUT -p tcp -s 192.168.0.0/24 --dport nfs -j ACCEPT -A INPUT -p udp -s 192.168.0.0/24 --dport nfs -j ACCEPT
So, you're saying that those 4 lines are easier than the 2 short ones in hosts.allow? Ah well, I'll have to learn to write iptables scripts then, I suppose.
It's a shame that you doesn't know how to write iptables scripts. (joke) tcp_wrappers are so old and so limited. I'm proud that archlinux drop this. Regards, -- Sébastien Luttringer www.seblu.net
On Saturday 16 July 2011 12:06:34 Peggy Wilkins wrote:
The annoucement suggests that a major reason for dropping support is that it is "confusing" to end users. An easy solution to that is to make a default hosts.allow file that says "ALL : ALL : ALLOW" out of the box. Then those of use wanting to simply restrict access (useful in many scenarios) can change that default as needed. Technically this is what we did: without tcp_wrappers every input is accepted now.
You've to setup iptables to deny all input and accept only what you need. I never used iptables before, but now I find its syntax really simple, and powerful. -- Andrea
On 16-07-2011 18:13, Andrea Scarpino wrote:
Technically this is what we did: without tcp_wrappers every input is accepted now.
I'd say that if not using iptables most input was already being accepted anyway so not supporting tcp_wrappers at all will make users more aware of what is allowed in.
You've to setup iptables to deny all input and accept only what you need. I never used iptables before, but now I find its syntax really simple, and powerful.
And while you are at it you might want to consider restricting the allowed outbound ip/ports for good measure ;) -- Mauro Santos
On 07/16/2011 08:06 PM, Peggy Wilkins wrote:
I am an end user who is very unhappy about the removal of this option. I didn't even know dropping tcp_wrappers was under consideration; had I known that I would have spoken up with my vote against removing support.
The annoucement suggests that a major reason for dropping support is that it is "confusing" to end users. An easy solution to that is to make a default hosts.allow file that says "ALL : ALL : ALLOW" out of the box. Then those of use wanting to simply restrict access (useful in many scenarios) can change that default as needed.
i read the news entry couples of times and I don't get it how you reach this conclusion. Really, this is not the reason and I found your comment hilarious.
IMO for users who want to use this feature, the burden is on the end user to find which services support tcp wrappers and which don't. A default "allow" policy makes this simple.
users who want this feature can as well recompile the desire services with this support.
Surely I'm not the only tcp wrappers user out there. I will sorely miss this option and strongly wish it to remain.
-- Ionuț
On Sat, Jul 16, 2011 at 3:23 PM, Ionut Biru <ibiru@archlinux.org> wrote:
On 07/16/2011 08:06 PM, Peggy Wilkins wrote:
The annoucement suggests that a major reason for dropping support is that it is "confusing" to end users. An easy solution to that is to make a default hosts.allow file that says "ALL : ALL : ALLOW" out of the box. Then those of use wanting to simply restrict access (useful in many scenarios) can change that default as needed.
i read the news entry couples of times and I don't get it how you reach this conclusion. Really, this is not the reason and I found your comment hilarious.
I was referring to this: "Additionally, newer daemons and applications are inconsistent in their support for libwrap, leading to confusion as to whether an application supports the library." This is true, it is confusing. My response was to say, well, change the default config then, and that criticism won't carry the same impact. (To be honest I have no idea what Arch's default config is for /etc/hosts.{allow|deny} because I edit it within minutes of a new install, but it seems that if it were default allow for ALL then it wouldn't cause as much trouble for people who wonder why sshd or whatever isn't working...)
users who want this feature can as well recompile the desire services with this support.
I will again say I chose Arch because I don't have to spend my time doing that (for a desktop OS); I very much appreciate the people who put the time into compiling things so I don't have to. I spend a fair amount of time compiling software at work, and I don't want a larger list of things to recompile regularly. I am not intending on continuing to bore everyone with my opinion here... I still wish support would stay, but it's not my decision, I just wanted to speak up in case anyone but me cared (and apparently I really am the only one...).
On Sat 16 Jul 2011 15:47 -0500, Peggy Wilkins wrote:
On Sat, Jul 16, 2011 at 3:23 PM, Ionut Biru <ibiru@archlinux.org> wrote:
On 07/16/2011 08:06 PM, Peggy Wilkins wrote:
The annoucement suggests that a major reason for dropping support is that it is "confusing" to end users. An easy solution to that is to make a default hosts.allow file that says "ALL : ALL : ALLOW" out of the box. Then those of use wanting to simply restrict access (useful in many scenarios) can change that default as needed.
i read the news entry couples of times and I don't get it how you reach this conclusion. Really, this is not the reason and I found your comment hilarious.
I was referring to this:
"Additionally, newer daemons and applications are inconsistent in their support for libwrap, leading to confusion as to whether an application supports the library."
This is true, it is confusing. My response was to say, well, change the default config then, and that criticism won't carry the same impact. (To be honest I have no idea what Arch's default config is for /etc/hosts.{allow|deny} because I edit it within minutes of a new install, but it seems that if it were default allow for ALL then it wouldn't cause as much trouble for people who wonder why sshd or whatever isn't working...)
users who want this feature can as well recompile the desire services with this support.
I will again say I chose Arch because I don't have to spend my time doing that (for a desktop OS); I very much appreciate the people who put the time into compiling things so I don't have to. I spend a fair amount of time compiling software at work, and I don't want a larger list of things to recompile regularly.
I am not intending on continuing to bore everyone with my opinion here...
I still wish support would stay, but it's not my decision, I just wanted to speak up in case anyone but me cared (and apparently I really am the only one...).
I think it makes sense to have only one place to control traffic, makes things a little simpler. tcp_wrappers is like a helper program for beginner users to control traffic, but you can most likely find a program that would help beginners to create iptable rules. I don't use them so I can't advocate any particular program though. Cheers.
I mentioned that I consider tcp_wrappers to be a DAC, someone asked me to clarify on MAC and DAC systems, so I put up a blog post: http://red45.wordpress.com/2011/07/17/mac-and-dac-core-security-concepts/
On Sun, Jul 17, 2011 at 01:56:58PM -0600, Thomas S Hatch wrote:
I mentioned that I consider tcp_wrappers to be a DAC, someone asked me to clarify on MAC and DAC systems, so I put up a blog post:
http://red45.wordpress.com/2011/07/17/mac-and-dac-core-security-concepts/
You equate MAC = whitelist DAC = blacklist Used as such they are redundant, you could just say white/blacklist instead. I've seen other definitions: MAC: imposed on all applications, they can't opt out and it doesn't require their support. According to this, iptables is a MAC even if can be configured either in whitelist or blacklist style as you show in your blog. DAC: voluntary, only applies to those apps that have been compiled or set up to use it. In this sense tcp_wrappers is a DAC. So we reach the same conclusion, but from different definitions. Ciao, -- FA
On Sun, Jul 17, 2011 at 2:18 PM, Fons Adriaensen <fons@linuxaudio.org>wrote:
On Sun, Jul 17, 2011 at 01:56:58PM -0600, Thomas S Hatch wrote:
I mentioned that I consider tcp_wrappers to be a DAC, someone asked me to clarify on MAC and DAC systems, so I put up a blog post:
http://red45.wordpress.com/2011/07/17/mac-and-dac-core-security-concepts/
You equate
MAC = whitelist DAC = blacklist
Used as such they are redundant, you could just say white/blacklist instead. I've seen other definitions:
MAC: imposed on all applications, they can't opt out and it doesn't require their support. According to this, iptables is a MAC even if can be configured either in whitelist or blacklist style as you show in your blog.
DAC: voluntary, only applies to those apps that have been compiled or set up to use it. In this sense tcp_wrappers is a DAC.
So we reach the same conclusion, but from different definitions.
Ciao,
-- FA
I like it, I think that we agree, iptables is a MAC that can be configured logically to act as a DAC, whereas tcp_wrappers is just a DAC. I should clarify in my blog post that I am trying to show the concept of what MAC and DAC are, rather than the implementation classification. Thanks for the clarity :)
On Sat, Jul 16, 2011 at 3:23 PM, Loui Chang <louipc.ist@gmail.com> wrote:
On 07/16/2011 08:06 PM, Peggy Wilkins wrote:
The annoucement suggests that a major reason for dropping support is that it is "confusing" to end users. An easy solution to that is to make a default hosts.allow file that says "ALL : ALL : ALLOW" out of the box. Then those of use wanting to simply restrict access (useful in many scenarios) can change that default as needed.
I think it makes sense to have only one place to control traffic, makes things a little simpler. tcp_wrappers is like a helper program for beginner users to control traffic, but you can most likely find a program that would help beginners to create iptable rules. I don't use them so I can't advocate any particular program though.
I haven't used it myself, but Uncomplicated Firewall (UFW) is available in the Community repository and looks like a simple alternative way to get going. https://wiki.archlinux.org/index.php/Firewalls#ufw ...and there are a handful of other similar firewall configuration tools listed on that page as well. Just thought it might be useful to point out for people following this thread. -- Aaron Bull Schaefer http://elasticdog.com/
What do the devs intend to do with packages that depend on tcp_wrapper such as syslog-ng, xinetd and esound which is a dependency of gstreamer? Richard.
Am 16.07.2011 23:00, schrieb Richard Ullger:
What do the devs intend to do with packages that depend on tcp_wrapper such as syslog-ng, xinetd and esound which is a dependency of gstreamer?
Richard.
None of those depends on tcp_wrappers.
On Sat, Jul 16, 2011 at 3:04 PM, Thomas Bächler <thomas@archlinux.org>wrote:
Am 16.07.2011 23:00, schrieb Richard Ullger:
What do the devs intend to do with packages that depend on tcp_wrapper such as syslog-ng, xinetd and esound which is a dependency of gstreamer?
Richard.
None of those depends on tcp_wrappers.
For those packages that have tcp_wrappers listed as deps, they can all be built without tcp_wrapper support. the tcp_wrapper package provides NO additional functionality required by any application. It can be removed cleanly.
Hello list, I've been using tcp_wrappers on Linux for more than 10 years, and on Archlinux for 6 years. FWIW I'm not happy about this change. Even though I know that the same functionality is provided by iptables, I consider tcp_wrappers the Unix Way. Anyway there is no value in fighting about personal opinions, and I respect the developers' decision because tcp_wrappers is unmaintained. Hopefully someone will move forward, fork the package and bring it up to date. Dimitris
participants (15)
-
Aaron Bull Schaefer
-
Andrea Scarpino
-
Dimitrios Apostolou
-
Fons Adriaensen
-
Ionut Biru
-
Jelle van der Waa
-
Loui Chang
-
Mauro Santos
-
Peggy Wilkins
-
Richard Ullger
-
Seblu
-
Thomas Bächler
-
Thomas S Hatch
-
Tom Gundersen
-
Vic Demuzere