Re: How to check UID of process on the other side of local TCP/UDP connection
"Greg Metcalfe" <[email protected]> Mon, 27 Nov 2006 18:31:42 -0800
| Newsgroups | gmane.comp.security.linux |
|---|---|
| Message-ID | <[email protected]> |
On Friday 24 November 2006 10:11, [email protected] 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