How to check UID of process on the other side of local TCP/UDP connection

[rainmailbox2001-ola]

Hello.

I have the following situation:
- Client communicates with server via TCP or UDP.
- Both client and server are on the same local host.
- Server runs with root privilege.

Now, client connects to server. Server has to check uid of the client. How it can be done?
I need a solution that can be ported to all modern Unix and Linux systems.

The most simple solution I came with is as follows:
1. Client connects to server.
2. Server asks client to create file with random name, for example /tmp/check.6723
3. Client generates the file.
4. Server checks the owner of the file.

The owner of the file is the UID under which client is running.

But
the problem is that it requires some additional communication between
server and client. My programs can communicate hundreds times a second
so creating, checking and removing the file is a big performance issue.

Do you have any ideas how this local authentication can be achieved in some different way?

I
was also thinking about using Unix sockets for communication, but it
seems that they also lack any mechanism for authenticating the client.
Anyways, I would prefer to stick with TCP/UDP, because this is what my
programs use already, and  I don't really want to change everything to
Unix sockets (unless of course Unix sockets are the only good way to
resolve my problems).

Thanks,
Ola

[Vladimir Mitiouchev-2]

On 11/24/06, rainmailbox2001-ola@... <rainmailbox2001-ola@...> wrote:
> Do you have any ideas how this local
> authentication can be achieved in some
> different way?
identd
fstat (BSD)
lsof(Linux)

> Unix sockets (unless of course Unix sockets are
> the only good way to
> resolve my problems).
SCM_CREDS (BSD)
SO_PEERCRED (Linux)

--
Sincerely Yours,
Vladimir Mitiouchev

[Luciano Rocha]

On Fri, Nov 24, 2006 at 10:11:39AM -0800, rainmailbox2001-ola@... wrote:
> I
> was also thinking about using Unix sockets for communication, but it
> seems that they also lack any mechanism for authenticating the client.

man 7 unix:
...
setsockopt(.., SO_PASSCRED, ...);
...
ANCILLARY MESSAGES
       Ancillary data is sent and received using  sendmsg(2)  and
recvmsg(2).
...
       SCM_CREDENTIALS
              Send or receive Unix credentials.  This can be used for authen-
              tication.   The  credentials are passed as a struct ucred ancil-
              lary message.

                struct ucred {
                    pid_t pid;    /* process ID of the sending process */
                    uid_t uid;    /* user ID of the sending process */
                    gid_t gid;    /* group ID of the sending process */
                };

              The credentials which the sender specifies are  checked by  the
              kernel.   A process with effective user ID 0 is allowed to spec-
              ify values that do not match its own.

> Anyways, I would prefer to stick with TCP/UDP, because this is what my
> programs use already, and  I don't really want to change everything to
> Unix sockets (unless of course Unix sockets are the only good way to
> resolve my problems).

Or you can try parsing the output of netstat (with option -p in Linux) or
lsof (eg: lsof -i 4@...:4015 for a connection from localhost,
port 4015).

--
lfr
0/0

[druid-2]

does doing a netstat and matching the client port with a pid work for you?

netstat -taonp
tcp        0      0 10.100.40.2:2617        69.31.131.44:22         ESTABLISHED 6038/ssh            keepalive (5790.02/0/0)

so the client/port 10.100.40.2:2617 is pid 6038

the server knows the following about the client:
source port
IP

so if I match sourceip:sourceport from the active connections table and
look for the pid matching that entry...

does that work for you? perhaps I misunderstood your question

-Eric

On Fri, 24 Nov 2006, rainmailbox2001-ola@... wrote:

> Hello.
>
> I have the following situation:
> - Client communicates with server via TCP or UDP.
> - Both client and server are on the same local host.
> - Server runs with root privilege.
>
> Now, client connects to server. Server has to check uid of the client. How it can be done?
> I need a solution that can be ported to all modern Unix and Linux systems.
>
> The most simple solution I came with is as follows:
> 1. Client connects to server.
> 2. Server asks client to create file with random name, for example /tmp/check.6723
> 3. Client generates the file.
> 4. Server checks the owner of the file.
>
> The owner of the file is the UID under which client is running.
>
> But
> the problem is that it requires some additional communication between
> server and client. My programs can communicate hundreds times a second
> so creating, checking and removing the file is a big performance issue.
>
> Do you have any ideas how this local authentication can be achieved in some different way?
>
> I
> was also thinking about using Unix sockets for communication, but it
> seems that they also lack any mechanism for authenticating the client.
> Anyways, I would prefer to stick with TCP/UDP, because this is what my
> programs use already, and  I don't really want to change everything to
> Unix sockets (unless of course Unix sockets are the only good way to
> resolve my problems).
>
> Thanks,
> Ola
>
>
>
>
>

[Bond Masuda]

I'm not sure why you would want to create files to check UID. Since you have
control of the server and client code, why not just use 'getuid' or
'geteuid' unix system calls? If you don't know what they are, run "man
getuid" for more information. This would be the simplest and most direct way
of getting UID information.

If you're wanting an "authentication" protocol, I think it is quite easy to
use TLS/SSL and require server/client certificates for authentication. You
would of course, require a basic CA setup. A lot of this code is already
available via the OpenSSL libraries so it shouldn't be hard to integrate
into whatever you're writing. Even if you write your own authentication
mechanism, you might want to check out the facilities available to you in
the OpenSSL libraries as any type of "secret" passing authentication should
not be done in cleartext. Your UID checking being an example of that. (sniff
the wire, pickup proper UID, spoof the server, serve up the UID)

Hope that helps...
-Bond Masuda
Security Consultant
-----------------------------------
JL Bond Consulting / www.JLBond.com

> -----Original Message-----
> From: listbounce@...
> [mailto:listbounce@...] On Behalf Of
> rainmailbox2001-ola@...
> Sent: Friday, November 24, 2006 10:12 AM
> To: focus-linux@...
> Subject: How to check UID of process on the other side of
> local TCP/UDP connection
>
> Hello.
>
> I have the following situation:
> - Client communicates with server via TCP or UDP.
> - Both client and server are on the same local host.
> - Server runs with root privilege.
>
> Now, client connects to server. Server has to check uid of
> the client. How it can be done?
> I need a solution that can be ported to all modern Unix and
> Linux systems.
>
> The most simple solution I came with is as follows:
> 1. Client connects to server.
> 2. Server asks client to create file with random name, for
> example /tmp/check.6723 3. Client generates the file.
> 4. Server checks the owner of the file.
>
> The owner of the file is the UID under which client is running.
>
> But
> the problem is that it requires some additional communication
> between server and client. My programs can communicate
> hundreds times a second so creating, checking and removing
> the file is a big performance issue.
>
> Do you have any ideas how this local authentication can be
> achieved in some different way?
>
> I
> was also thinking about using Unix sockets for communication,
> but it seems that they also lack any mechanism for
> authenticating the client.
> Anyways, I would prefer to stick with TCP/UDP, because this
> is what my programs use already, and  I don't really want to
> change everything to Unix sockets (unless of course Unix
> sockets are the only good way to resolve my problems).
>
> Thanks,
> Ola
>
>
>
>
>

On Friday 24 November 2006 10:11, rainmailbox2001-ola@... wrote:

> Hello.
>
> I have the following situation:
> - Client communicates with server via TCP or UDP.
> - Both client and server are on the same local host.
> - Server runs with root privilege.
>
> Now, client connects to server. Server has to check uid of the client. How
> it can be done? I need a solution that can be ported to all modern Unix and
> Linux systems.
>

See the getuid(2) and geteuid(3p) man pages. Whatever language you're writing
in probably has the system call.
> The most simple solution I came with is as follows:
> 1. Client connects to server.
> 2. Server asks client to create file with random name, for example
> /tmp/check.6723 3. Client generates the file.
> 4. Server checks the owner of the file.
>
That's just *nasty*.
> The owner of the file is the UID under which client is running.
>
> But
> the problem is that it requires some additional communication between
> server and client. My programs can communicate hundreds times a second
> so creating, checking and removing the file is a big performance issue.
>
Yep, you need IPC.
> Do you have any ideas how this local authentication can be achieved in some
> different way?
>
You want to use a UID for authentication???
> I
> was also thinking about using Unix sockets for communication, but it
> seems that they also lack any mechanism for authenticating the client.
> Anyways, I would prefer to stick with TCP/UDP, because this is what my
> programs use already, and  I don't really want to change everything to
> Unix sockets (unless of course Unix sockets are the only good way to
> resolve my problems).
>
Unix sockets really would make more sense. This is what they're *for*.
Why have another TCP/UDP service, running as root, if there's any way to avoid
it? Even if it's only a localhost listener, it's possibly an easier elevation
of privilege or DoS attack. Using the stack is also more expensive.

Plus, you have socketpair(2) to simplify your coding. A quick Google will give
you the details on that. It should simplify your code, no matter the
language. And you should have an implementation, as it's another system call.

As this is a security list, it's pretty much obligatory for me to always
recommend simplification, if only to maintain the habit. ;)

You have to realize that sockets only provide a means of communication. What
you *do* with your communications link, whether that be authentication or
streaming the digits of pi, is up to you, and has to be coded.

> Thanks,
> Ola

Have fun,

Greg Metcalfe

[Pranay Kanwar]

I would suggest you use a authentication
mechanism, Since the server only authenticates local clients i would recommend the local passwd
authentication scheme.

Also the thing to notice is you basically need
some type of access control, and access control requires three things authentication, authorization and accountablity, if you miss any there will be loop holes.

Regards,
warl0ck - MSG
http://www.metaeye.org

[Michael Bacarella-2]

/*
 * On Mon, Nov 27, 2006 at 09:06:30PM +0100, Vladimir Mitiouchev wrote:
 * > On 11/24/06, rainmailbox2001-ola@... <rainmailbox2001-ola@...>
 * > wrote:
 * > >Do you have any ideas how this local
 * > >authentication can be achieved in some
 * > >different way?
 * > identd
 * > fstat (BSD)
 * > lsof(Linux)
 * >
 * > >Unix sockets (unless of course Unix sockets are
 * > >the only good way to
 * > >resolve my problems).
 * > SCM_CREDS (BSD)
 * > SO_PEERCRED (Linux)
 *
 *  Use getpeereuid()
 *
 * Here's an implementation if your system doesn't provide it libc.
 */

#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;
}

/*
 *
 * --
 * Michael Bacarella <mbac@...>
 *
 *  1-646-641-8662 (cell)
 *
 * 545 Eighth Avenue * Suite 401
 * New York, NY 10018
 *
 * http://michael.bacarella.com/
 * http://netgraft.com/
 *
 */

[Ghint]

>
>> Anyways, I would prefer to stick with TCP/UDP, because this is  
>> what my
>> programs use already, and  I don't really want to change  
>> everything to
>> Unix sockets (unless of course Unix sockets are the only good way to
>> resolve my problems).

I don't want to go off-topic but i have an important question. Isn't  
a socket a concept that translates an address and port? How would  
someone go about doing tcp/udp without sockets when they both depend  
on address/port mappings which are _literally_ sockets?

Am i wrong?

Thanks for reading

Filipe

On Monday 27 November 2006 12:06, Vladimir Mitiouchev wrote:
> On 11/24/06, rainmailbox2001-ola@... <rainmailbox2001-ola@...>
wrote:

> > Do you have any ideas how this local
> > authentication can be achieved in some
> > different way?
>
> identd
> fstat (BSD)
> lsof(Linux)
>
> > Unix sockets (unless of course Unix sockets are
> > the only good way to
> > resolve my problems).
>
> SCM_CREDS (BSD)
> SO_PEERCRED (Linux)

SO_PEERCRED isn't supported on HP-UX 11i for PA-RISC, at least. I think there
are some hoops to jump through in using SCM_CREDS. This may have all been
resolved for HP-UX versions for Itanic, though. I have no idea what might be
involved on AIX.

I think the most portable solution (O.P. wants portability across all modern
Unices) would be via the OpenSSL libs. There are vendor supported packages
available for Solaris, HP-UX, and AIX--probably pretty much the last of the
commercial Unices he has to worry about.

As the O.P. needs hundreds of connections per second, this might be too
expensive. But it would probably keep his porting work to a minimum.
--
Greg Metcalfe

[Vladimir Mitiouchev-2]

On 11/28/06, Filipe Varela <fcv@...> wrote:
> I don't want to go off-topic but i have an important question. Isn't
> a socket a concept that translates an address and port? How would
> someone go about doing tcp/udp without sockets when they both depend
> on address/port mappings which are _literally_ sockets?
> Am i wrong?
Yes, You are.
Sockets are abstractions.
In fact, socket is an end-point of a bi-directional communication link.
It can be Unix, Internet Domain, some kind of IPC, whatever.
Google... :-)

--
Sincerely Yours,
Vladimir Mitiouchev

[Michael T. Babcock]

rainmailbox2001-ola@... wrote:
> I have the following situation:
> - Client communicates with server via TCP or UDP.
> - Both client and server are on the same local host.
> - Server runs with root privilege.
>  
Are you using the sockets for something other than this authentication?  
You could use shared memory (not always portable) or unix sockets as
some have suggested, or simply use named pipes for that matter.

Are you using the UIDs of the files for anything interesting, or just to
make sure nobody else created the file on you?  If you're just doing
this to make sure the client is who it claims to be, use a different
authentication system like a cryptographically strong hash function.

Decide what you care about:  Do you care what the UID is for security
purposes, or just to make sure the same user created the file and is
talking to you?  Do you need the file for processing, or is it just an
out-of-band security system?  Do you need the socket for communication
of anything else, or is it just the security system?

If you're processing real files with data in them, create the file
securely (put users and server in the same group, make directory only
writable and usable by the group, etc.) with whatever metadata you need
inside it and then open a unix socket connection to your server app
telling it the name of the file and the SHA-1 (or other) hash of the
file you created (preferably with a negotiated salt involved).  The
server can then process the file and make sure the signature matches,
and move on.

If its an insecure server, consider using real digital signatures,
perhaps kerberos authentication for clients and servers.  There are lots
of good options out there.

--
Michael T. Babcock
Triple PC Ltd.

[Glynn Clements]

Filipe Varela wrote:

> >> Anyways, I would prefer to stick with TCP/UDP, because this is  
> >> what my
> >> programs use already, and  I don't really want to change  
> >> everything to
> >> Unix sockets (unless of course Unix sockets are the only good way to
> >> resolve my problems).
>
> I don't want to go off-topic but i have an important question. Isn't  
> a socket a concept that translates an address and port? How would  
> someone go about doing tcp/udp without sockets when they both depend  
> on address/port mappings which are _literally_ sockets?
>
> Am i wrong?

I think that you misunderstood.

By "Unix sockets", he was referring to using Unix-domain sockets
(AF_LOCAL) rather than TCP/IP sockets (AF_INET).

Unix-domain sockets have the advantage that you can obtain the
identity (PID, UID, GID) of the peer from the OS.

--
Glynn Clements <glynn@...>

[Luciano Rocha]

On Tue, Nov 28, 2006 at 05:17:09PM +0000, Filipe Varela wrote:

> >
> >>Anyways, I would prefer to stick with TCP/UDP, because this is  
> >>what my
> >>programs use already, and  I don't really want to change  
> >>everything to
> >>Unix sockets (unless of course Unix sockets are the only good way to
> >>resolve my problems).
>
> I don't want to go off-topic but i have an important question. Isn't  
> a socket a concept that translates an address and port? How would  
> someone go about doing tcp/udp without sockets when they both depend  
> on address/port mappings which are _literally_ sockets?

I don't really understand your question nor where did the concept of
doing tcp/udp without sockets originated.

Maybe you're misreading the term Unix sockets? Sockets can belong to
different protocol families: INET, INET6, UNIX/LOCAL, X25, etc..

Unix sockets means using sockets for local interprocess communication.
They don't use any network protocol.

man 7 unix

--
lfr
0/0

[Ghint]

Hi all

I'll clarify my question as i seem to have failed to make it clear.

My point is: Isn't it wrong to use the term unix sockets for local  
domain sockets? This isn't a tecnical question or a failure to  
understand what sockets are, what varieties exist and for what  
purposes each can be used (and what goodies each type provides). It's  
a failure to understand why the term unix sockets is used to  
designate local domain sockets.

The point in using the tcp/udp example is that contrary to popular  
designation, the sentence "doing tcp/udp is impossible with unix  
sockets because unix sockets are local domain sockets" is false. Unix  
sockets are the general class. While it's true that local domain  
sokets do not use tcp/udp, it's false (and this is a conceptual stand  
not an everyday unix jargon use) that unix sockets = local domain  
sockets.

Hierarchy

UNIX SOCKET {
        local domain
        ipv4/6
        etc
        etc
}

And this is the view that i would like you to tell me is right or  
wrong (i'm not standing by it, just asking what you consider it to be).

Thanks for reading




On 2006/11/29, at 20:57, Luciano Miguel Ferreira Rocha wrote:

> On Tue, Nov 28, 2006 at 05:17:09PM +0000, Filipe Varela wrote:
>>>
>>>> Anyways, I would prefer to stick with TCP/UDP, because this is
>>>> what my
>>>> programs use already, and  I don't really want to change
>>>> everything to
>>>> Unix sockets (unless of course Unix sockets are the only good  
>>>> way to
>>>> resolve my problems).
>>
>> I don't want to go off-topic but i have an important question. Isn't
>> a socket a concept that translates an address and port? How would
>> someone go about doing tcp/udp without sockets when they both depend
>> on address/port mappings which are _literally_ sockets?
>
> I don't really understand your question nor where did the concept of
> doing tcp/udp without sockets originated.
>
> Maybe you're misreading the term Unix sockets? Sockets can belong to
> different protocol families: INET, INET6, UNIX/LOCAL, X25, etc..
>
> Unix sockets means using sockets for local interprocess communication.
> They don't use any network protocol.
>
> man 7 unix
>
> --
> lfr
> 0/0

On Wednesday 29 November 2006 11:49, Michael T. Babcock wrote:

> rainmailbox2001-ola@... wrote:
> > I have the following situation:
> > - Client communicates with server via TCP or UDP.
> > - Both client and server are on the same local host.
> > - Server runs with root privilege.
>
> Are you using the sockets for something other than this authentication?
> You could use shared memory (not always portable) or unix sockets as
> some have suggested, or simply use named pipes for that matter.
>
> Are you using the UIDs of the files for anything interesting, or just to
> make sure nobody else created the file on you?  If you're just doing
> this to make sure the client is who it claims to be, use a different
> authentication system like a cryptographically strong hash function.
>
> Decide what you care about:  Do you care what the UID is for security
> purposes, or just to make sure the same user created the file and is
> talking to you?  Do you need the file for processing, or is it just an
> out-of-band security system?  Do you need the socket for communication
> of anything else, or is it just the security system?
>
> If you're processing real files with data in them, create the file
> securely (put users and server in the same group, make directory only
> writable and usable by the group, etc.) with whatever metadata you need
> inside it and then open a unix socket connection to your server app
> telling it the name of the file and the SHA-1 (or other) hash of the
> file you created (preferably with a negotiated salt involved).  The
> server can then process the file and make sure the signature matches,
> and move on.
>
> If its an insecure server, consider using real digital signatures,
> perhaps kerberos authentication for clients and servers.  There are lots
> of good options out there.

If this were Slashdot, I'd probably be posting to request a 'mod parent up'.
Parent post was the first to mention named pipes, for instance.

It's very common to get a bunch of replies from talented people who are
answering in idle moments. Read: don't want to go into the subject of one of
my pet peeves; not having enough information to really help the OP much.
Asking good questions in an original post is hard. Strike that--asking good
questions is hard, period. Doing it politely, on a mailing list, is harder
still.

Babcock has done this. IMHO, ball is in OP's court; without more info, much
wheel-spinning will result.

--
Greg Metcalfe

[Luciano Rocha]

On Thu, Nov 30, 2006 at 06:02:02PM +0000, Filipe Varela wrote:

> Hi all
>
> I'll clarify my question as i seem to have failed to make it clear.
>
> My point is: Isn't it wrong to use the term unix sockets for local  
> domain sockets? This isn't a tecnical question or a failure to  
> understand what sockets are, what varieties exist and for what  
> purposes each can be used (and what goodies each type provides). It's  
> a failure to understand why the term unix sockets is used to  
> designate local domain sockets.
>
> The point in using the tcp/udp example is that contrary to popular  
> designation, the sentence "doing tcp/udp is impossible with unix  
> sockets because unix sockets are local domain sockets" is false. Unix  
> sockets are the general class. While it's true that local domain  
> sokets do not use tcp/udp, it's false (and this is a conceptual stand  
> not an everyday unix jargon use) that unix sockets = local domain  
> sockets.

No. There's the socket API, and then there's unix sockets. You can use
a api similar to sockets in windows, but you can't use unix sockets
(local domain sockets) in windows.

The socket API isn't limited to Unix based/like systems, but the unix
sockets, as far as I know, and I don't know *that* many different
operating systems, is.

Maybe an unfortunate name to call it, but it became the common one.

--
lfr
0/0

[Glynn Clements]

Filipe Varela wrote:

> I'll clarify my question as i seem to have failed to make it clear.
>
> My point is: Isn't it wrong to use the term unix sockets for local  
> domain sockets?

No. If you look at the PF_* AND AF_* macros in <sys/socket.h> (or
<bits/socket.h> in glibc-2), you will see something like:

#