[ On Wednesday, November 15, 2000 at 22:37:01 (-0600), Eric Haszlakiewicz wrote: ]
> Subject: Re: Addition to force open to open only regular files
>
> 	and you don't consider writing over what you just wrote to the
> tape to be destructive?  What if you happen to have a tape that can
> hold more than what you will write at once?  Why should whatever you
> have writing to the tape (dump, dd, whatever..) have to be smart enough
> to realize it's a tape, then issue a special ioctl so the next run will
> write after it?  Instead of having the device know what to do in certain
> cases now you'll have to teach every tool that you might want to use the
> device.  

That's not what I was saying at all!

The problem isn't that a spurious open() can cause device handling
problems, but rather that unauthorised users can fool a set-ID program
into open()ing an arbitrary file.

> 	Here's another idea: say you have a device that enforces exclusive access
> (e.g. an audio device).  The device node has permissions to prevent joe
> user from opening it.  Using a setuid program that does a supposedly safe
> open/fstat/close joe user points it at the audio device, then suspends the
> process. oh gee...  looks like I can't use my sound card anymore.

That's not going to work the way you suggest unless the audio driver has
a bug in it, esp. since this "joe" characters will be unable to subvert
a program that does open()/fstat()/close()-on-error sufficiently to fool
it into keeping the device open for sufficiently long to inhibit your
next access of the audio device.

Besides if you're paying attention you'll see the difference between an
error condition such as ENXIO, EFAULT, ENODEV, or EIO, and the EBUSY
that'll be returned if "joe" succeeds and you'll realise that someone
else is fooling with your device somehow.


[ On Wednesday, November 15, 2000 at 22:49:33 (-0600), Eric Haszlakiewicz wrote: ]
> Subject: Re: Addition to force open to open only regular files
>
> 	So write() is bad and read() is bad, but not as much.  Saying that
> open() must be ok is needlessly limiting what behavior a device can
> be defined to do on open (and implicitly, on close).  Opening a device
> can do various things: allocating memory, setting flags, changing
> hardware state, generally using system resources.  I do not believe that
> it is broken to allow devices to do things like this.  

Strictly speaking most of those things are not normally done in a
properly designed device driver -- or if they are they're
non-destructive and not too intrusive.  About the only thing that might
be considered normal would be some forms of hardware state changes to
reflect the fact that a program has opened the device on the software
side, such as raising DTR on a serial port or locking the manual eject
mechanism on a removable media device.  A well designed device interface
will even permit multiple simultaneous opens.  Open(2)'s job is just to
check permissions, accessibility, start the device if it needs
"starting", etc. and to hand back a file descriptor, and normally
nothing more.  Yes it may allocate resources, but those resources will
be released upon close (i.e. once the program finds out it has opened a
device by mistake/subversion :-).

In any case this isn't the real problem, as you say:

> I also think that
> if the permissions on the device node forbid a particular user from accessing
> the device they should not be able to cause the system to use those
> resources.

Well now, that's what we're talking about, isn't it!

If a program can be subverted into even just open()ing and fstat()ing
random file (and then closing it perhaps) then I'd say there's a design
flaw in that program (and/or the library subroutines it might call
upon).

It seems to mee that the obvious solution to this problem is to
re-design or remove the feature that's causing the problem in the first
place, not to re-design the entire system so that this feature can be
used safely as-is!

Changing paradigms and potentially requiring major changes in large
numbers of security-sensitive programs is an undertaking that must not
be done without a great deal of careful consideration.  Doing all of
this just to make one poorly designed feature of questionable utility
work is almost certainly the wrong approach.

> 	just because you don't use a feature doesn't mean no one else should.

I want to see people lay down solid requirements for such a feature
before I jump through twisting burning hoops just to try and make it
safe to use, and I want them to show how such a feature can be secured
so that it won't be abused or subverted too!

As I said before, name-to-location mapping is a highly sensitive system
service that probably should not be allowed to be subverted, not even by
local users who purport to know what they're doing.  $HOSTALIASES could
potentially subvert a privileged application into connecting to the
wrong host (as could $LOCALDOMAIN).  After all you don't let the user
specify an alternate name for /etc/passwd, now do you!

Perhaps if lots of users would cry the blues if these features were
removed then the best compromise to simply fix privileged and/or set-ID
programs to ignore them (hopefully by putting such checks directly in
the library routines which implement these features) and then to live
with the inconsitencies in program behaviour that will result.

Otherwise I would say $HOSTALIASES and $LOCALDOMAIN support just has to
go away completely and users can either practice their typing skills
and/or learn to make better use of other UI features that'll help them
enter fully qualified names where the way the system default search
features are configured are not to their liking.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>