[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: hurd does NOT need /hurd

On Tue, May 21, 2002 at 11:23:58AM +1000, Anthony Towns wrote:
> On Mon, May 20, 2002 at 07:49:49PM -0400, Michael Stone wrote:
> > > > It's also correct, from a certain point of view. </obi-wan> There is a
> > > > school of thought that firewalls are only useful if you are trying to
> > > > protect network services that you can't secure properly.
> > > Which is quite accurate. We can't secure our services properly. If we
> > > could, we would have, and we wouldn't be wasting time worrying about
> > > making sure we can do security updates in a timely manner.
> > Again, if you have no faith at all in the security of your service, the
> > only useful firewall rule is "DENY" from "ALL", which is equivalent to
> > "don't listen". 
> No, that's not the case. If I have faith in the reliability of the
> service in normal use, but none in its security, I ensure that it's only
> accessible by *people* I have faith in. I can do that with firewalling
> tools.

Why do you need faith in reliability of the service running? Just
don't give it any permission on the system.
> > For that matter, why are you complaining about the lack
> > of a firewall in hurd while our default install has network services
> > without even the firewall that you use as a security blanket?
> Because I'm not talking about defaults. Nor am I talking about things that
> everyone will be compelled to use. I'm talking about features that *must*
> be made available for me to be able to look someone in the eye and say
> "Yes, Debian GNU/Hurd 3.1 is ready for your use."

The Hurd has more security features than Linux has. I have never seen
a password server for Linux for example.

> > > > More importantly, for this school of thought, is the fact
> > > > that firewalls offer a false sense of security. 
> > > Actually, they offer a much *stronger* sense of security. It's easier
> > > to say "Don't allow any traffic from this device to port 80" with a
> > > system-wide firewalling tool and be confident that nothing's going to
> > > get in, than to do the same thing from the application.
> > How do you feel more confident that the firewall won't break than that a
> > web server won't magically install itself? 
> I may've already installed a webserver that I'm happily accessing from
> another interface.

It would have been better if you have a port 80 cabability and could
give that to apache. Then apache could be running without uids. 
> > At any rate, the point isn't that I won't allow the use of firewalls,
> > but that they aren't an essential element of all security models. tb
> > overstated his point, but it shouldn't be dismissed.
> I've no idea why you're overstating my point like that. A firewall is
> a necessary feature of a modern operating system. If users choose not
> to make use of that feature, that's their decision, and good luck to
> them. I'm not sure I have an opinion on whether default firewalling rules
> would be a help or a hindrance.

On 30 years old operating systems like unix it might be. Modern
operating systems like GNU/Hurd don't need a firewall. It even gives
everybody a login shell when they telnet in without any problems.

A system like the Hurd has something called security by design. I
think it's easier to eliminate all suid binaries and make all daemons
run with uids by default than to implement firewalling in the
Hurd. The shell you get when you telnet to the system doesn't have any
uids so it doesn't impact security (it only has a higher theoretical
security risk).
> Anyway. The Hurd needs some basic firewalling tools.

If you really insist on those firewalling things we can make a deal,
if you eliminate all suid binaries for Debian GNU/Linux I make sure
that the Hurd has firewalling functionality like netfiler. And I'm
even friendly for you now, I could've asked you to make all daemons
runs without uids by default. :-)

Jeroen Dekkers
Jabber ID: jdekkers@jabber.org  IRC ID: jeroen@openprojects
GNU supporter - http://www.gnu.org

Attachment: pgpxWzcPrCv_q.pgp
Description: PGP signature

Reply to: