[Dev] Access control design for user applications
casey.schaufler at intel.com
Wed Apr 16 16:00:51 GMT 2014
> -----Original Message-----
> From: Dev [mailto:dev-bounces at lists.tizen.org] On Behalf Of Patrick Ohly
> Sent: Wednesday, April 16, 2014 4:03 AM
> To: Rafał Krypa
> Cc: dev at lists.tizen.org
> Subject: Re: [Dev] Access control design for user applications
> On Wed, 2014-04-16 at 12:07 +0200, Rafał Krypa wrote:
> > On 2014-04-16 09:13, Patrick Ohly wrote:
> > > How will the app receive the reply if it can't read from the "User"
> > > domain? My guess is that this works because the data that it needs
> > > to read was explicitly written to by a service in the "User" domain,
> > > but I am not sure.
> > Communication over UDS requires only write permissions. The client
> > (connecting side) needs write access to the server. The server should
> > also require write access to the client. The latter was found missing
> > is Smack as well, but it's already patched (not backported to Tizen
> > kernel yet).
> So when connecting to the UDS of a service, the client does fd =
> socket(AF_UNIX, SOCK_STREAM), then connect(fd, path), and it will get a
> read/write fd connected to the service even if it only has write access to the
> socket's label. Okay, I'm starting to understand, I suppose.
The key is that IPC that doesn't use "objects" (SVIPC uses objects that
have labels, whereas signals and socket based IPC don't) make access
checks using labels attached to the receiving process. Because it's a
blind write (you can't get information the other side doesn't send) only
write access is required. The other side needs to be able to write to
you for stream connections. There is technically no read access check
anywhere in the process because once the information has been
delivered it is in your process.
UDS has filesystem entries, but if you look carefully you'll see that the
Smack label is always "*" on them. This reduces the complexity of inode
handling and is safe because the access checks are done on connect
for stream and packet delivery for datagrams.
> Best Regards, Patrick Ohly
> The content of this message is my personal opinion only and although I am an
> employee of Intel, the statements I make here in no way represent Intel's
> position on the issue, nor am I authorized to speak on behalf of Intel on this
> Dev mailing list
> Dev at lists.tizen.org
More information about the Dev