Newsgroups: comp.org.eff.talk
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!barmar
From: barmar@think.com (Barry Margolin)
Subject: Re: Software vendor liability/culpability
Message-ID: <1991Jun11.041330.11911@Think.COM>
Sender: news@Think.COM
Reply-To: barmar@think.com
Organization: Thinking Machines Corporation, Cambridge MA, USA
References: <43086@cup.portal.com> <1991Jun9.143317.25764@Think.COM> <43140@cup.portal.com>
Date: Tue, 11 Jun 91 04:13:30 GMT
Lines: 39

In article <43140@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes:
>The original poster said something like "some BSD based systems" when
>talking about the /dev entry.  I don't know enough about BSD networking
>to know if unprotecting the /dev entry would cause a problem on *all* BSD
>based systems.  Would it?

BSD networking doesn't use /dev at all.  I thought the original posting was
a hypothetical question about a general class of possible problems.

>On System V (or, at least, the SCO version of System V when using the
>Lachman implementation of TCP/IP), I don't think that there would be
>a problem, because the streams driver for the network card determines
>what stream to send an incoming packet to based on the packet type.
>The TCP/IP software should already have a stream opened to the driver
>for all IP packets, so someone coming in later would not be able to
>grab these.  

Some Unix networking implementations provide a way for a suitably
privileged process to view packets going through the network driver without
affecting whether they are received by the intended process (Sun's
etherfind and the publically-available tcpdump make use of this facility to
turn a Unix box into a network monitor).  For networks implemented through
a /dev entry, I could easily imagine this being done by opening the device
and then doing an appropriate ioctl(), and the ability to do this might be
controlled by the protection on the device file.

>	      Do any BSD systems work like this?  If so, the vendor might
>be able to argue that a particular system that does not behave like this
>is at fault.

A vendor who claims their software works on a particular system can't claim
after the fact that the system "should" behave a certain way.  If they've
qualified their software for that system, then it should be designed for
the way that system *does* behave, not how they would like it to behave.
-- 
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar