Re: More on garbage
From: Nick Maclaren (nmm1_at_cus.cam.ac.uk)
Date: 06/16/05
- Next message: David Wagner: "Re: More on garbage"
- Previous message: koostos: "videocrypt"
- In reply to: David Wagner: "Re: More on garbage"
- Next in thread: David Wagner: "Re: More on garbage"
- Reply: David Wagner: "Re: More on garbage"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: 16 Jun 2005 08:43:17 GMT
In article <d8qc13$1a2l$1@agate.berkeley.edu>,
David Wagner <daw-usenet@taverner.cs.berkeley.edu> wrote:
>Nick Maclaren wrote:
>> A "deny all except X, Y and Z" can cause broken programs to
>> fail if they test P, decide that there is no networking, and
>> still listen to X. It is therefore a FACTOR if that causes a
>> breach of security.
>
>I need more explanation. The idea is that the firewall builder starts
>with "deny all", and only allow service X if he/she understands X
>(and all apps that implement it) well enough to be sure it is safe
>to allow. Are you implicitly assuming that the firewall implementor
>didn't understand service X?
Yes, of course. Some of the other replies have been close to my
meaning, but not usually very close.
In practice, it is VERY rare for the designer or implementor of
a firewall to know the exact (network) properties of the programs
that need to be run within that firewall. Even when he knows the
complete list (which is rare), it is almost unknown for them to
specify their networking properties in detail.
It is very common for the action of opening or closing a port to
allow program A or close attack B to have a consequential effect
on program C. That program's test suite (if any!) may not use that
port, but program C may be sensitive to it. The consequence is that
you have made an unknown change to the behaviour of a program with
an unknown specification.
If that program has a relevant bug or, worse, an undocumented or
well-hidden 'feature' where it has undefined behaviour if port P
is open but port Q is closed, your actions in configuring the
firewall are a FACTOR in causing that program to be a security
exposure on your system (where it may well not be on a system with
no firewall).
This is exactly the analogue of the insanities I was caught by in
the use of fancy memory management in compilers. Let me merge a
couple of problems for example.
A compiler rejects a perfectly valid program with a syntax
error. It turns out that this happens only if memory limits are in
force (even if they are 1,000 times the size of the physical memory).
The vendor points out that there is an unindexed file which states
that limits must not be set when running this compiler, and says that
this is my error.
I point out that not setting those means that simple finger trouble
by a user is likely to (and has) caused the entire system to die so
badly that I had to do a binary chop on the running jobs, with a
manual power-cycle for each test. It took two days :-(
The vendor refused to accept the point that the incompatibility
between its compiler and its system control facility is unreasonable.
I am told to select which one I want for my (sic) program (note the
singular).
Polite words fail me.
Regards,
Nick Maclaren.
- Next message: David Wagner: "Re: More on garbage"
- Previous message: koostos: "videocrypt"
- In reply to: David Wagner: "Re: More on garbage"
- Next in thread: David Wagner: "Re: More on garbage"
- Reply: David Wagner: "Re: More on garbage"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
