On Wed, 6 Dec 2000, Greg A. Woods wrote:

> Remember that "privileged use of tainted data", and "accidentally
> opening a rewind tape device" are two completely separate and unrelated
> problems.

  They certainly are related: the unauthorized tape rewind is only
possible because of the privileged use of tainted data that occurs with
HOSTALIASES and such when run as the privileged ID.  If run with the real
id, it can still cause problems later but prevents the immediate
privileged use of tainted data.

> Unless you make setuid go away sompletely you've not likely gained very
> much additional security, at least not in a general sense....

  The idea is that those who want to turn it off may do so, while those
that want to run third party set-id programs still can do so.  At some
point it may be possible to default it off or remove it completely,
however that large of a change would need a transition period.

> >  Many things that use
> > setuid (and all that are truely necessary for basic system operation)
> > should be done by appropriate kernel protection (new syscalls if
> > necessary).
>
> Examples of such things would be???

  Kernel statistics and reserved ports are the easist to implement,
however in general I think the kernel should do fine grained protection on
all resources (based on users, not binaries).

> >  The rest can easily be done with IPC.  An inetd type daemon
> > could be used to run the daemons only when necessary.
>
> Hmm...  "easily" is not a word I'd use to describe what it would
> take...  While AF_LOCAL sockets can pass credentials, there are still
> some messy details to worry about.

    The only problem I can think of is DOS attacks, which can be helped by
fair queueing and resource limits.

> >   These should be started by an inetd type daemon, not by set-id.  This
> > way the user has no influence over the environment, cwd, or anything else
> > that might affect its operation.
>
> So all you've really done is move setuid into user-land then, and
> potentially introduced just as many new caveats as you may have
> eliminated old ones....

  Except that with IPC the only interaction between the calling user and
the privileged code is through the socket, while with set-id there are a
number of ways to influence the program (environment, cwd, etc.).  Not
being prepared for these various interactions is what caused many of the
setuid problems to begin with, and with set-id you will have to continue
to monitor any new interactions.

> I.e. ftpd must always start as the superuser, one way or another (even
> if you've got an authentication daemon such as the Cyrus pwcheck
> program).

  Running ftpd as user ftp would need an ACL system to grant user ftp
access to those files.  Now that I think about it, this would be much less
secure then a root authenticated daemon and generally a very bad idea.

> The problem with the silly port-20 thing is that you need to bind a
> socket to it potentially many times *after* you've authenticated the
> user, which means that if you use setuid() to permanently drop down to
> the user's privileges the only way to "reserve" the port is to reserve
> it to a specific process-ID and have some kind of unreserve-on-exit
> feature such that a new process with the same ID can't exploit the port
> too.

  You would associate the ability with the struct proc, not the process
id.  It should not be difficult at all.

> While such a mechanism could be implemented, it's probably no easier to
> do than it would be to simply use a restricted unprivileged group-ID to
> invoke a little setuid-root helper process that would hand back a socket
> descriptor that's already bound to port 20, just as I described some
> time ago, or perhaps with a broker daemon that accepts AF_LOCAL requests
> with credential passing so that it can verify that the requesting
> process is running with the restricted effective group-ID for ftpd, and
> which then passes back a file descriptor for the already-bound socket.

  This would actually be less secure since it gives the user access to
port 20, not just ftpd.

> I.e. there's no reason why the kernel can't simply dishonour such
> calls and thus the library can still to contain the function and the
> system call can remain in the syscall table -- it just doesn't do
> anything any more but return an error (and perhaps log its use).

  This breaks previously working binaries, which needs a major version
bump.  It would be easy enough to do the needed emulation of setreuid() in
libc, which would remove any incompatibility.

Matthew Orgass
darkstar@pgh.net