Re: Secure client/server file processing (was: How to check UID of process on the other side of local TCP/UDP connection)

On Wednesday 29 November 2006 11:49, Michael T. Babcock wrote:
> [email protected] 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