[ On Wednesday, November 22, 2000 at 17:58:49 (+1100), Luke Mewburn wrote: ]
> Subject: Re: A possible solution to ftpd port 20 binding
>
> Another solution is to have a central file descriptor broker daemon,
> which you communicate with via an authenticated AF_LOCAL socket.
> The broker checks the creds against an access control list (defined in
> a config file), and if ok, passes back a file descriptor over the socket.

A central broker seems way over-kill vs. a simple tiny group-exec-only
protected setuid-root binary that can do the same thing (i.e. hand back
the socket FD to its parent).  I guess it's a matter of scale, though I
can't quite imagine the number of programs needing this facility
exceeding any threshold that would justify the existence of such a
complex solution.

I'm not quite sure what an "authenticated AF_LOCAL socket" is either,
unless you just mean one to which setsockopt(..., LOCAL_CREDS, ...); has
been applied.

> This same concept could be extended to other files that need to access
> a file as another user; just ask the broker which checks your creds
> against its ACL for that file.

hmmmm....

So, just exactly who is allowed to open a privileged socket?  The
credentials returned from the client over a Unix-domain socket only
reveal the real and effective IDs, and the login name and of course the
current set of supplementary group-IDs).  If you do a setuid(getuid())
before calling the socket broker then you've clobbered just about all
the possible information that could be used to authorise the binding of
a privileged socket, save perhaps that maybe you've first added a unique
special purpose group to the suppl. groups (thus possibly having to
trash an existing one if the user was already at NGROUPS).  Of course
this same limitation holds for a stand-alone setuid-root helper program
that simply hands back an already bound socket filedescriptor since that
program has to be protected from generic execution too.....

I think I'd still go for a custom separate helper program.  It's a *lot*
simpler, easier to configure, harder to mess up, and not inefficient
enough to cause any real concern (how often do you have to bind a
privilege socket anyway?).  The only scary part might be that it
probably has to exist within a chroot(), but then again that's not a lot
different than having to have a socket file for the broker.

> If this would work as a concept, and we had an API for this (in -lutil
> or wherever) could we even use it to solve the $HOSTALIASES problem for
> set-id programs? I.e, the application sends a request to the broker for
> a file descriptor, the broker forks a child to run as the target uid
> which opens the file as the real user and passes the file descriptor
> back to the setuid program. Or would that be too inefficient?

For the environment variables problem I think open_as() is one heck of a
lot more efficient, not to mention simpler to use, and of course it has
zero administrative overhead too!  :-)

The fact that open_as() doesn't solve the privileged ports problem can
even be looked at as a feature too!

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