[Dev] Tizen 3.0 proposal for fixing OSP/WRT/Core hard-coded UID issue

Schaufler, Casey 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
> broken.

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
> information.
> _______________________________________________
> Dev mailing list
> Dev at lists.tizen.org
> https://lists.tizen.org/listinfo/dev

More information about the Dev mailing list