Re: getpeereid() for Linux

Re: getpeereid() for Linux

[Jesse Pollard]

Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE>
> Michael Bacarella <mbac@nyct.net> writes:
> 
> > There's no need. The equivalent functionality can already be
> > implemented in userspace.
> 
> Well, it doesn't work with TCP.  Uh-oh, I see I forgot to mention the
> following: I need this functionality for local TCP connections, not
> just UNIX domain sockets.

It doesn't work on BSD either. The manpage says:
(http://www.openbsd.org/cgi-bin/man.cgi?query=getpeereid&sektion=2&apropos=0&mnpath=OpenBSD+Current)

     getpeereid() returns the effective user ID and group ID of the peer con-
     nected to the UNIX domain socket s.

     One common use is for UNIX domain servers to determine the credentials of
     clients that have connected to it.

It is not possible to get a creditential from TCP connections yet. That
requires an extension to IPSec to even be able to carry credentials. There
is no reliable communication path (even for identd) to be able to pass
credentials.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: getpeereid() for Linux

[Florian Weimer]

Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil> writes:

> It is not possible to get a creditential from TCP connections yet. That
> requires an extension to IPSec to even be able to carry credentials. There
> is no reliable communication path (even for identd) to be able to pass
> credentials.

I need the credentials only for local connections, though.  This is
technically possible.  A userspace implementation partially cloning
ident seems to be a possible approach.

-- 
Florian Weimer 	                  Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Re: getpeereid() for Linux

[H. Peter Anvin]

Followup to:  <tgd755vdl9.fsf@mercury.rus.uni-stuttgart.de>
By author:    Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE>
In newsgroup: linux.dev.kernel
> 
> I need the credentials only for local connections, though.  This is
> technically possible.  A userspace implementation partially cloning
> ident seems to be a possible approach.
> 

Since it will only work locally anyway, just use a Unix domain socket
-- that's what they're for.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: getpeereid() for Linux

[Florian Weimer]

Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil> writes:

> > I need the credentials only for local connections, though.  This is
> > technically possible.  A userspace implementation partially cloning
> > ident seems to be a possible approach.
> 
> It won't be reliable.

I don't think so.  At least the 

> Even the documentation for ident (at least the version I looked at a
> while ago, might be different now, but I don't think so) says that
> the data returned is not reliable. (even fuser doesn't always get
> this right when trying to identify processes with open sockets).

The trick is not to identify processes.

> Part of the problem is that TCP sockets don't carry the same information
> that domain sockets have (could be partially wrong here, it just may not
> be filled in since the source of the data can't supply it).

Fortunately, they do carry the necessary data in the Linux kernel.
Otherwise, you would have a pretty hard time to implement the
netfilter owner match rules.

My current approach is the following: fstat() the socket to get its
inode, look up the inode in /proc/net/tcp to get a (local, remote)
pair.  Swap the pair and search /proc/net/tcp again to get the UID the
other end.  No race condition is possible because the kernel may not
create a new (remote, local) pair because we hold open the (local,
remote) socket, so even a SO_REUSEADDR will not do the trick.

> The other part is that it depends on what allocated the socket.

Yes, that might be a problem, but this affects netfilter as well.  The
kernel structure records the effective UID of the process at the time
of the creation of the socket.  It might have changed afterwards.

> Ownership is established at socket allocation time, and the socket
> can be passed to a totally different user. Identity of the user of
> the socket is therefore lost.

Hmm, you can always forward connections, so this isn't a problem.  If
some decides to give his credentials away, he is free to do so. ;-)

-- 
Florian Weimer 	                  Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Re: getpeereid() for Linux

[Jesse Pollard]

Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE>:
> 
> Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil> writes:
> 
> > It is not possible to get a creditential from TCP connections yet. That
> > requires an extension to IPSec to even be able to carry credentials. There
> > is no reliable communication path (even for identd) to be able to pass
> > credentials.
> 
> I need the credentials only for local connections, though.  This is
> technically possible.  A userspace implementation partially cloning
> ident seems to be a possible approach.

It won't be reliable. Even the documentation for ident (at least the version
I looked at a while ago, might be different now, but I don't think so) says
that the data returned is not reliable. (even fuser doesn't always get this
right when trying to identify processes with open sockets).

Part of the problem is that TCP sockets don't carry the same information
that domain sockets have (could be partially wrong here, it just may not
be filled in since the source of the data can't supply it). The other
part is that it depends on what allocated the socket. Ownership is established
at socket allocation time, and the socket can be passed to a totally different
user. Identity of the user of the socket is therefore lost.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: getpeereid() for Linux

[Florian Weimer]

Michael Bacarella <mbac@nyct.net> writes:

> There's no need. The equivalent functionality can already be
> implemented in userspace.

Well, it doesn't work with TCP.  Uh-oh, I see I forgot to mention the
following: I need this functionality for local TCP connections, not
just UNIX domain sockets.

-- 
Florian Weimer 	                  Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Re: getpeereid() for Linux

[Michael Bacarella]

> Would anyone like to give me a helping hand in implementing the
> getpeereid() syscall for Linux?  See the following page for the
> documentation of the OpenBSD implementation:
> 
> http://www.openbsd.org/cgi-bin/man.cgi?query=getpeereid&sektion=2&apropos=0&manpath=OpenBSD+Current
> 
> I think I could work out the kernel data structures to gather the
> relevant data from, however, I won't get all the locking stuff right.
>
> OTOH, is there any chance that the addition of such a syscall would be
> accepted?

There's no need. The equivalent functionality can already be
implemented in userspace.

------

#include <sys/socket.h>

uid_t getpeereuid(int sd)
{
	struct ucred cred;
	int len = sizeof (cred);

	if (getsockopt(sd,SOL_SOCKET,SO_PEERCRED,&cred,&len))
		return -1;

	return cred.uid;
}

------

The same can be done for gid, and even pid.

Yes, Linux rules.

-- 
Michael Bacarella <mbac@nyct.net>
Technical Staff / System Development,
New York Connect.Net, Ltd.

Re: getpeereid() for Linux

[Florian Weimer]

Andi Kleen <ak@suse.de> writes:

> SO_PEERCRED doesn't need any cooperation from the other end (at least 
> not for SOCK_STREAM) 

Thanks.  Over here, SO_PEERCRED is documented in socket(7). ;-)

> There is netfilter owner match, but it is a bad hack.

I certainly don't want to give a user process the right to add
netfilter rules dynamically. :-/

> I think you're better off with identd. 

Or some /proc parsing (which is probably what identd does, too).

-- 
Florian Weimer 	                  Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Re: getpeereid() for Linux

[Andi Kleen]

On Wed, Sep 05, 2001 at 12:05:50PM +0200, Florian Weimer wrote:
> Andi Kleen <ak@suse.de> writes:
> 
> > Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE> writes:
> > 
> > > Would anyone like to give me a helping hand in implementing the
> > > getpeereid() syscall for Linux?  See the following page for the
> > > documentation of the OpenBSD implementation:
> > 
> > It is implemented for unix sockets (see unix(7))
> 
> Hmm, it is not documented in my local copy (?).  getpeereid() is
> different from the standard credential passing mechanism because it
> does not require cooperation of the other end.

SO_PEERCRED doesn't need any cooperation from the other end (at least 
not for SOCK_STREAM) 

> > For TCP it is rather useless because it would work only locally.
> 
> Obviously, we need it only locally. ;-) The interface is useful if you
> are implementing poor man's VPN in user space.

There is netfilter owner match, but it is a bad hack.

I think you're better off with identd. 

> 
> > If you trust the localhost you're probably better off using the
> > ident protocol for it.
> 
> This means running just another server, even with root privileges. :-(

identd doesn't need root.

-Andi

Re: getpeereid() for Linux

[Florian Weimer]

Andi Kleen <ak@suse.de> writes:

> Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE> writes:
> 
> > Would anyone like to give me a helping hand in implementing the
> > getpeereid() syscall for Linux?  See the following page for the
> > documentation of the OpenBSD implementation:
> 
> It is implemented for unix sockets (see unix(7))

Hmm, it is not documented in my local copy (?).  getpeereid() is
different from the standard credential passing mechanism because it
does not require cooperation of the other end.

> For TCP it is rather useless because it would work only locally.

Obviously, we need it only locally. ;-) The interface is useful if you
are implementing poor man's VPN in user space.

> If you trust the localhost you're probably better off using the
> ident protocol for it.

This means running just another server, even with root privileges. :-(

-- 
Florian Weimer 	                  Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Re: getpeereid() for Linux

[Andi Kleen]

Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE> writes:

> Would anyone like to give me a helping hand in implementing the
> getpeereid() syscall for Linux?  See the following page for the
> documentation of the OpenBSD implementation:

It is implemented for unix sockets (see unix(7))
For TCP it is rather useless because it would work only locally. If you trust
the localhost you're probably better off using the ident protocol for it.

-Andi

getpeereid() for Linux

[Florian Weimer]

Would anyone like to give me a helping hand in implementing the
getpeereid() syscall for Linux?  See the following page for the
documentation of the OpenBSD implementation:

http://www.openbsd.org/cgi-bin/man.cgi?query=getpeereid&sektion=2&apropos=0&manpath=OpenBSD+Current

I think I could work out the kernel data structures to gather the
relevant data from, however, I won't get all the locking stuff right.

OTOH, is there any chance that the addition of such a syscall would be
accepted?

Thanks to /proc, it is possible to implement the user ID part of the
syscall in userland, at least for TCP sockets, but this isn't enough.
(I've got a such an implementation which seems to work quite well,
just in case you are interested.)

-- 
Florian Weimer 	                  Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898