>>>>> "Jonathan" == Jonathan Stone <jonathan@DSG.Stanford.EDU> writes:

    Jonathan> You (like others in this thread) are taking the
    Jonathan> perceived threats, risks, and associated costs from your
    Jonathan> own environment, and then proceeding as if those risks
    Jonathan> are universal.  This may come as a surprise to you, but
    Jonathan> in fact, they *aren't* universally applicable.

You are wrong on two counts. First of all, you have no knowledge of
the perceived threats and risks in my own environment. This means it
is presumptious of you in the extreme to suggest that I am projecting
those concerns to a wider stage. [Fact: my NetBSD box is a standalone
device, not connected to anything but the public electricity supply.]
Secondly, many of the security problems I have identified are
universal. For example if you have NFS, you pretty much have to accept
the risks of filehandle forgery and weak authentication, assuming you
know these exist. And the availability of that knowledge is another
story...

    Jonathan> PLEASE NOTE: that doesn't mean you're wrong about those
    Jonathan> assumptions holding in your home, or workplace, or
    Jonathan> wherever-it-is that they're valid.  It just means there
    Jonathan> are other environments with different perceived risks,
    Jonathan> and where different costs are placed on those risks.
    Jonathan> Which means your blanket statements about security don't
    Jonathan> hold in *those* environments.  Okay?

No. Weak security systems and badly written or designed software *is*
a problem. However, as you rightly say, whether someone chooses to
accept those problems and deal with them depends on local
circumstances. It does not excuse developers and vendors shipping
bad code. I could live with that if the documentation said things
like "if you enable foo, there is a real danger that someone could
exploit loophole bar to do....". However, life's not like that.

    Jonathan> Mistake #1.  In some situations, firealls can help
    Jonathan> enormously.  It depends on what the perceived risks are,
    Jonathan> and the kind of firewall you deploy. Firewalls help *me*
    Jonathan> a lot.  I haven't had to worry about any of the
    Jonathan> on-campus NFS breakins, from either off-campus or
    Jonathan> on-campus, because my group is behind a firewall.  If
    Jonathan> you have a machine at home with a continuous Internet
    Jonathan> connection, and your financial information is online,
    Jonathan> then you better beleive a firewall can help a *lot*.

True, but you've taken my remarks out of context. Which was that
someone suggested (or at least implied) that a firewall would stop NFS
attacks based on forging or stealing file handles. I rightly pointed
out that threat this was more of a risk internally than from the Big
Bad Internet and thus a firewall was little help.

Fact: I worked at a company where management and the security officer
believed their computer systems were "secure" because they had bought
an expensive firewall to keep the Big Bad Internet at bay. Meantime,
there was no security policy (let alone enforcement of one), there
were setuid-root shell scripts on the operational servers, privileged
passwords written down on bits of paper, MS-Turd macro viruses and all
sorts of others security horrors going on. And this was in an
environment where safety and security was "important". There, the
firewall did not help security at all. As you say, it all depends on
circumstances.

    >> All this does is remove one not very significant threat.

    Jonathan> Mistake #3.  The amount of threat it removes depends
    Jonathan> very much on the environment under consideration.  If
    Jonathan> you have a small workgroup where everyone knows the root
    Jonathan> password, and you set up a firewall around that enclave,
    Jonathan> then the ``threat'' that is removed by a firewall is
    Jonathan> pretty much all threats, save for physical attacks.

Again, you take my remarks out of context. The risk of NFS file handle
forgery is far, far greater inside the security perimiter than outside
it. After all, the firewall is supposed to stop undesirable traffic
to/from the outside world however that is defined, right?

    >> The big danger comes from the internal users

    Jonathan> Mistake #4.  That may be true for whoever runs the
    Jonathan> corporate payroll (where "internal" means "anyone who
    Jonathan> gets paid"), or inside Philips, or in other corporate
    Jonathan> internets, or in ``data centers''. It's certainly *not*
    Jonathan> true in general.  One obvious counter-example is most
    Jonathan> research universities, where in general it doesn't hold
    Jonathan> at all.  Having access to an IP address in the range
    Jonathan> belonging to the organisation is often sufficient to
    Jonathan> gain access to all sorts of online information.

Again, you take my remarks out of context. Internal users - however
you choose to define them - present more of a danger because they are
usually more trusted (rightly or wrongly) by the organisation's
network resources than external users.

    Jonathan> Mistake #5.  The ``internal users'' might not need any
    Jonathan> means to do ``evil things'', they might already have
    Jonathan> them.  They might not have the motive.  They certainly
    Jonathan> have the opportunity.  But doing ``evil thing on the
    Jonathan> LANs'' around here, more often than not, means
    Jonathan> accidentally saturating an Ethernet segment with NFS
    Jonathan> requests to the point where nobody can ping the NFS
    Jonathan> server and the machine has to be rebooted.

If that's the only problem you have to deal with, then I'm glad for
you. Now it's you who's projecting *your* security considerations on
the rest of the world....