On Tue, 25 Apr 1995, Peter da Silva wrote:
Naturally, this whole discussion is about theory vs practice. Both sides
are pointing out things which are true. I think Mr. Cohen's position is
approximately stated as: 'If you can't *prove* it's secure, it could have
problems. Particularly suspect areas are in the boundary conditions which
few if any programmers test or even consider'
To which Marcus, among others have said: 'This theory stuff is nice in a
classroom, but doesn't happen in the real world. If you can give us an
example of where your theory meets up with our software, cough it up.'
To which Mr. Cohen has offered a few generic examples of security
problems which have at best limited applicability here.
> > I have discussed. I offer as
> > evidence of the continued existence of these potential flaws, the
> > eternal <defunct> processes that still exist even in modern versions of
> > Unix.
>
> Why are these a problem? You have to store the exit status for a dead
> process somewhere, and you can't reuse the process-id until the parent's
> picked it up, so why *not* use an empty process structure?
>
Is Mr Cohen asserting that these defunct processes can somehow be brought
back to life by other than there original userid? That *would* be a
security hole, but the worst problem I know of defunct processes causing
is denial-of-service from resource exhaustion.
> > Sure - the defunct process problem, the failed logging problem that
> > results from resource exhaustion, the problem with NFS pointed to above,
>
> If you run NFS on your firewall you're already dead.
>
True, but you overlooked the bit about logging. I would expect it'd be
pretty easy to have the proxies not continue if they can't keep an audit
log, tho most people in the real world don't lose any sleep over this one.
> > Even when a file system cache error causes a block of the deny
> > file to be read as a block of the allow file?
>
> I have never heard of this sort of error happening on any UNIX file system,
> ever.
Well, a file system cache error could be caused by hardware, but if we're
to consider this a possibility then we can't even count on a 20 line
mathematically proven correct program executing properly.
And it's worth noting here that the fwtk doesn't have seperate allow and
deny files, so we're still 0-for on examples of practical problems with
fwtk on unix.
>
> > Yes, this sort of behavior
> > has been detected under certain versions of NFS and Novell and has been
> > published for some time.
>
> NFS is not a UNIX file system, and neither is Novell. They are network file
> systems. If your firewall is depending on the security of network resources
> it's not a firewall at all.
>
> (if you really want to know why NFS isn't a UNIX file system, mail me under
> separate cover)
If Mr Cohen thinks Novell and NFS have anything to do with the types of
firewalls generally discussed on this list, I respectfuully suggest he's
reading the wrong list.
I appreciate and accept that there are no practical tools available today
that allow one to produce provably correct code. And I appreciate that
holes are most likely to show up 'at the boundary conditions', as Mr.
Cohen maintains.
Given those items, I'd really like to see any examples of how the fwtk
code running on unix might be driven to fail security, when each and
every piece is written to deny service if *anything* goes wrong.
--- David Miller
----------------------------------------------------------------------------
It's *amazing* what one can accomplish when
one doesn't know what one can't do!
Follow-Ups:
References:
|
|
