[Dev] Tizen 3.0 proposal for fixing OSP/WRT/Core hard-coded UID issue
casey.schaufler at intel.com
Thu Oct 10 16:15:13 GMT 2013
> -----Original Message-----
> From: dev-bounces at lists.tizen.org [mailto:dev-bounces at lists.tizen.org] On
> Behalf Of Jussi Laako
> Sent: Thursday, October 10, 2013 7:36 AM
> To: dev at lists.tizen.org
> Subject: Re: [Dev] Tizen 3.0 proposal for fixing OSP/WRT/Core hard-coded
> UID issue
> > Not at all. You call recvmsg and the getsocopt to get the SO_PEERCRED.
> > The "other" process exits. Another process gets created with the same
> > pid. You open /proc/PID/something. You get the wrong data. The
> > mechanism is 100% unreliable.
> Except that you know that the other process has quit because the socket got
Only if you look, and you still don't know if the other side broke the connection and is still running or if it died and there's a different process running with the same pid.
> 1) You get data from socket and issue getsockopt()
> 2) You read /proc/PID
> 3) You validate (2) by checking that the (1) is still intact and the socket peer is
> still owned by the same PID
Except that the original process could have close()d the socket and still be running, so the test in (3) yields a false negative. And, how do you do validate that "(1) is still intact"?
> Even if it did fork() and exec() to pass the descriptor onward it purposefully
> voluntarily did give it's own privileges to the child.
> This use of stream sockets is generally bad and for this purpose there
> should exist a datagram socket where each datagram will get security
> context attached to it at the time of send and received as ancillary
> data in recvmsg(). Or even better still, expand the more efficient POSIX
> message queues (mq_open()/mq_send()/mq_receive()) to hold this
> Dev mailing list
> Dev at lists.tizen.org
More information about the Dev