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

AW: hurd does NOT need /hurd

> Von: Anthony Towns [mailto:aj@azure.humbug.org.au] 
> On Tue, May 21, 2002 at 03:43:50PM -0700, Thomas Bushnell, BSG wrote:
> > Anthony Towns <aj@azure.humbug.org.au> writes:
> > > Firewalling tools are provided with the Debian system. 
> Firewalling 
> > > tools are not available for Debian GNU/Hurd. Debian GNU/Hurd will 
> > > not be released until they are available.
> > I think that it is foolish to insist on this.  Router firewalling 
> > tools, for example, are not necessary unless the Hurd has router 
> > forwarding capacity
> Then provide host firewalling tools. I'm sure the Hurd can 
> act as a host.

Make up your mind and think over again, what Thomas said.

> > --which it does not, and is such a low priority we might never have 
> > it.
> Then you might never release. *shrug*

I don't know exactly what kind of firewalling support linux had before
2.0.x kernels
but I don't think it had been alot.

> > Similarly, we might have a totally different way of getting 
> whatever 
> > security benefits accrue to host-based firewalling.  I have no idea!
> If you have a totally different way of getting those security 
> benefits, then that counts as "firewalling tools" and this is 
> a null issue. Since you've got no idea, I suspect you don't 
> have such a way though.

What's the use of firewalling if nothing is actually listening on the

> Note that, following Linux's precedent, there's no need to 
> have your first implementation by elegant. You can rip it out 
> entirely when you think of a better way to do it, and have 
> all the userspace tools breaks, and just provide a kludgy 
> script to replace it, and people won't particularly mind.

Hmm, I rather have no firewalling support at all than having a crippled
one that's not reliable.

Anyway, Linux has given a good example by changing the VM within the
pissing off a lot of guys!

Did anybody of you Debian geeks realized the lack of actual
in contrast to the vast Linux-Developers in the past and now?

You are all welcome to join the Hurd and extend it's capabilities

> Let's try the Socratic method.

> Do you believe that firewalls can ever be helpful?

> Do you believe that blocking ports can ever be helpful?

> Do you believe the Hurd should be useful as a server?

Not in this state.

> Do you believe that people use a single machine as a gateway and a

see above answer

> Do you believe that -- even if the server can't do routing -- it can
still act as 
> a gateway by running, eg, a squid proxy and having two interfaces, one
for a LAN 
> and one for the Internet?

> Do you believe that it might be useful to use iptables to stop people
from the 
> Internet trying to access the proxy, whether to try a new security
hole, or just 
> to see what they can do?


> Do you believe that dedicated firewalls can break or be misconfigured?


> Do you believe that a server on a firewalled LAN (with public IP
addresses) that 
> shouldn't be able to be reached by the Internet, could be in such a


> Do you believe all software -- even site-written software -- that can
run on the 
> Hurd has its own access control, and that, in every case that access
control is 
> fine-grained and flawlessly written?


> Do you believe that there is any value in having a server that
shouldn't be reachable 
> from the Internet, running services whose access control software you
don't trust to 
> protect you, could usefully be protected (or further protected) by
blocking all access 
> from outside your LAN on the box you're using?


> Do you believe that application-level access control is perfect in all


> Do you believe that application-level access control is generally
higher quality code 
> than the Hurd implementation?


> Do you believe there are any cases when firewalling in the Hurd would
be more reliable 
> than application-level access control?


> Would you go "what the f$#k is going here?" if you bought a commercial
Unix that didn't 
> have any firewalling tools?

*) Do you believe it would be common (good?!?) practice by working
around the syptoms
   instead of actually get rid of the security leaks?
   As somebody told already, i.e. running X and have it listening for
incoming connections
   but complaining about security is the material, which lets people cry
for such tools.
   The listening port is the symptom and you will work around with a
firewall instead of
   turning of the feature.

   My personal believe is that a personal firewall is just a placebo
security gain.
   A system which has been desinged right shouldn't allow the access.

> Some other questions, for those of you who think Hurd might even
compete with Linux, 
> let alone be preferred to it within the next decade:

> Have you ever found the ability to do routing on a machine that you'd
usually think of 
> as a desktop useful?

Do you really expect such feature which desktops should have? What about
the security
problem right in front of your routing desktop, the user? Uuh, that's

> Do you really think anyone, given the choice between two systems with
mostly the same 
> software, would choose the one that can only be a leaf-node, rather
than the one that 
> can be either, depending on your needs at the time?

Do you really expect Windows as safe environment for doing such things?
It can be used as desktop and as server, but if you really believe it's
doing it reliable and 
safe, then you must be sick.

And Hurd in contrast to Linux, read the statement above about manpower
on the Linux vs. Hurd!

> Cheers,
> aj

Well, this thread makes me sick in the way of Debian-devel attitudes. 
Get down from your throne.
It's easy to complain, but hard to change something.

BTW: Why is (Debian/)Linux FHS compliant, if the annex wouldn't exist?
     Didn't see the /proc dir in the original FHS except the annex....

University Of Applied Sciences, Mittweida

To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: