"William E. Baxter" <[EMAIL PROTECTED]> writes:
> On Fri, May 04, 2001 at 05:07:38PM -0700, Alfred Perlstein wrote:
> > * Dima Dorfman <[EMAIL PROTECTED]> [010504 16:06] wrote:
> > > Is there a reliable method of obtaining the credentials (uid/gid) of a
> > > peer (SOCK_STREAM sockets only, obviously) on a unix domain socket?
> > > All the Stevens books I have suggest that there isn't, but I'm
> > > wondering if something has been developed since those books were
> > > published. Note that a BSD/OS-like LOCAL_CREDS socket opt is not
> > > sufficient because using the latter the process must wait until the
> > > peer sends something before they can learn its credentials. If this
> > > process intends to drop the connection if it's not from an authorized
> > > source, this may lead to a DoS attack. Timers don't help, either;
> > > think of TCP SYN flood-like attacks.
> >
> > Someone had some patches for a getpeercreds() syscall, but I wasn't
> > happy with it considering we already have the sendmsg() stuff to pass
> > credentials along with the fact that the initial creator of a socket
> > may be long gone before it's used to connect to something.
>
>
> I wrote that patch. Links to my patches appear at
>
> http://www.superscript.com/patches/intro.html
Cool! Actually, I wrote a patch[1] to implement something simlar
before sending my original e-mail. I looked at your patches, and it
seems the main difference is that mine uses the getsockopt interface
instead of a system call, and mine uses struct xucred which, I
believe, is the correct way of passing user credentials to the
userland (this structure didn't exist in FreeBSD 4.0, which is what it
looks like your patch is against). Other than that they do pretty
much the same thing :-).
> Explanatory material and links to the same appear at
>
> http://www.superscript.com/ucspi-ipc/getpeereid.html
>
> My patch is designed to satisfy these conditions:
>
> 1. Server can obtain credentials of connect() caller (effective uid and gid suffice).
> 2. Server can obtain credentials without depending on client to send data.
>
> Having met these conditions, it is nearly trivial to create privileged servers
> that run behind a unix socket, in an environment under their own control. In
> many instances one can replace setuid programs with such servers.
Just to expand on that a little more (for others on the list),
consider crontab(1). It's setuid root right now. Obviously that's
not good. One way of getting rid of that setuid bit is to have
cron(8) (or another daemon) listen on a world-writable unix domain
socket, and have crontab(1) just be a user interface which sends the
information via that socket. With some mechanism to get the
credentials of the user that connected, this would be possible.
Regards,
Dima Dorfman
[EMAIL PROTECTED]
[1] http://www.unixfreak.org/~dima/home/peercred.diff
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
