[ On Friday, November 24, 2000 at 04:27:16 (-0500), Matthew Orgass wrote: ]
> Subject: Re: Addition to force open to open only regular files
>
>   This is true except for the environment, which is still tainted or not
> depending on what you did or did not do previously.  Opening as the real
> user id just changes (or specifies) the documented behavior;  it does not
> actually fix anything.  While you can argue if the real id should be used
> or not, it does not address the real issue that tainted data is being
> used.

It certainly does fix the major problem here!  Normal users are not
permitted to open things like rewind-on-close tape drives, so using
open_as() in the library to open $TZ or $HOSTALIASES would prevent users
from clobbering backups or whatever.

It matters not if the data's tainted as long as the user can only do
damage to his or her own files.  I.e. it's arguable if you could even
claim the env var's contents are "tainted" in that case -- they might
not be valid, but they're not dangerous (to the system) any more.

>   It is just as easy to permanently drop privileges now.  Removing saved
> ids only make it impossible to temporarily drop privileges and do not
> change the fact that the environment must be untainted while in the higher
> privilege.  But if you can temporarily drop privileges, then you should
> always run in the lower privilege except for the exact places where you
> need the higher privilege.  In this case, opening files specified in
> environment variables would be done as the real user even if done as the
> effective id.

The *ONLY* gain in running with temporarily lowered privileges currently
is that you don't have to remember to drop them before calling any
system call which might make use of the process' effective-ID
credentials (and since this can happen inside library routines this
means the set-ID programmer doesn't have to be 100% familiar with all
such library routines).  Unfortunately does not prevent a buffer
overflow or printf format string exploit from regaining those privileges
and starting a root shell or whatever.  Which is more dangerous:  having
the programmer forget to do some file access as the real user; or having
a cracker exploit some rare overflow condition in the code to gain root
privileges?  I say the latter is because it is many times harder to
prove that code does not suffer from such vulnerabilities than it is to
prove that the the code always accesses files as the real user.

> > >  Disallowing library functions from accessing devices does
> > > not work when the kernel does not know that a file refers to a device (as
> > > could be the case on a network file system).
> >
> > Well, actually, any network file system which permits opens of devices
> > must clearly identify the fact that the file is a device to the client
> > kernel.  If this is not so then the remote filesystem in question is
> > extremely buggy and untrustworthy in the first place.
> 
>   Why?  The UNIX model designed devices to appear to be files that may
> have a few extra capabilities.  If these capabilities are not needed, then
> the only reason a kernel would need to care that it was a device was to do
> something special just because it was a device.

Why?  Because that's the way things work!  I don't know for sure about
AFS, but I do know that NFS and RFS certainly pass the device flag to
the remote client so that it's visible in a stat() call.  In the case of
NFS the client kernel does the device handling through its local device
drivers, and in the case of RFS the server kernel does the device
handling.  In either case the process doing the opening will be able to
see that it has opened a device if it does an fstat() on the open file
descriptor.

>  But you don't care if it
> is a device or not, you care if it has side effects, which with modern
> file systems might be the case with any file.

Yes, of course, which is why it's critical that when the contents of an
environment variable are treated as a filename that any access of the
file be done with the credentials of the real user.

>   There is no other real solution: the environment must be untainted.

Why?  So long as code that parses environment values is robust, and so
long as any access to files they might specify id done as the real user,
there's no real danger even if the environment is full of garbage values.

> While opening as the real id may help achieve that goal, it does not by
> itself solve the problem.

What problem are you trying to solve?

>  Further, file activity is not necessarily the
> only problem with the use of a tainted environment: anything that can
> alter the behavior of the program (or other programs acting for it) in
> ways not known by the programmer can potentially be a security problem.

The set-ID programmer must always be aware of all potential security
problems and all ways that the user might potentially affect the
operation of his or her program.

Of course this is only an ideal and sadly it is not reached all of the
time in all existing set-ID programs.

However, as Mr. Elz has said about tzfile parsing, code that's broken
and not robust enough to avoid crashing when handling garbage data is
presented to it must be fixed!

After all, one man's garbage is another's treasure!

>   Saved-set-ID provides this, it just isn't being used.

Actually, it is being used properly in a significant number of the
set-ID programs that I've examed recently!

>   Any effort directed to setuid security should be concentrated in the
> following areas:
> 1) Preventing the use of tainted data

Or fixing the code that can't deal with it robustly....

> 2) Pinpointing exact areas where higher privilege is needed
> 3) Documenting all of the above
> 
>   The use of tainted data will eventually loose no matter how many hoops
> you jump through.

Why?

-- 
							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>