Providing shared buffer for applications within Smack environment

[José Bollo]

On Tue, 12 Dec 2017 13:28:58 +0200
Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Tue, 12 Dec 2017 12:08:43 +0100
> José Bollo <jose.bollo at iot.bzh> wrote:
> 
> > On Tue, 12 Dec 2017 12:44:46 +0200
> > Pekka Paalanen <ppaalanen at gmail.com> wrote:
> >   
> > > On Tue, 12 Dec 2017 11:00:23 +0100
> > > José Bollo <jose.bollo at iot.bzh> wrote:
> > >     
> > > > Hi all,
> > > > 
> > > > While working for AGL [1], I want to allow applications to
> > > > receive the buffers allocated by WESTON. The use of the
> > > > surfaces/buffers allocated by Weston is difficult when Smack is
> > > > activated.      
> > > 
> > > Hi,
> > > 
> > > why do you need to make Weston allocate buffers? Why should those
> > > buffers be accounted to Weston rather than a client that needs
> > > them?    
> > 
> > TBH, I've no idea of the how and the why but I know that at the end
> > clients of the shell call this allocator and that if nothing is
> > done, the file descriptor can't be passed to the client because of
> > Smack label.
> > 
> > I can check the reason if you like but it will take some time. It is
> > probably a window manager feature.  
> 
> Hi,
> 
> I'm not too interested. If you can deliver the question for the
> protocol extension designers to ponder on, that would be enough.
> 
> Usually we try to make the compositor take as little "blame" on
> behalf of clients as possible. That includes all kinds of resource
> allocations and processing.
> 
> > > E.g. Weston's screenshooting currently has the client allocate
> > > buffers, pass them to Weston, and Weston writes into them, then
> > > sends an event to say they are done.
> > > 
> > > There are valid use cases, I'm sure, just checking for the
> > > obvious. 
> > > > When these buffers are created, they are tagged with the smack
> > > > security label that depends on the security label of the service
> > > > WESTON and of the security label of the directory
> > > > XDG_RUNTIME_DIR when Smack transmutation allows it (see [2]).
> > > > 
> > > > For the sake of keeping things simple, I wanted to just tune
> > > > how the buffers are created. But I had to reach the issue that
> > > > XDG_RUNTIME_DIR is also used for socket end point and for lock,
> > > > leading to a opposition of requirements on the objects created
> > > > in XDG_RUNTIME_DIR: some of them are for sharing and some other
> > > > have to be under control.      
> > > 
> > > The use of XDG_RUNTIME_DIR for allocating buffers is actually not
> > > the best way. I think nowadays we should move on to using
> > > shm_open() instead of creating temporary files in
> > > XDG_RUNTIME_DIR.    
> > 
> > From the Smack perspective, it probably means that the object is
> > tagged with the label of the process. This has implications for
> > Smacked systems.  
> 
> I'm not too familiar with Smack. Would programs need to do something
> special to be able to pass open file descriptors for other processes
> to use? I can certainly understand protecting the content of
> XDG_RUNTIME_DIR specifically, but what about in general, or for
> shm_open() in particular? After all, shm_open() primarily meant for
> inter-process sharing.

Not so simple at all! You are not able to share by default, conversely,
sharing must be explicitly stated by some rule.

shm_open allocates the IPC shm and attach it the security context of
the process that creates it. Any access to the shm requires an explicit
rule (or some few implicit rules like having the same label).

Using file and file system allows to create shared memory but with a
security label coming from the enclosing directory. This way the label
of the application (weston) can be still protected while the label of
the buffer is different (here it is shared to any application that
receive it because it is a kind of anonymous memory map).

This solution would not work with shm_open because the shm object is
sticked to the process. Even a privileged process can't change the
smack label of shm.

Conversely, I can mount XDG_RUNTIMESHARED_DIR with tmpfs to be sure
that there is absolutely nothing on "disk".

> If this is something inherent to Smack, maybe we could have something
> in upstream for it, but if it dependent on a particular Smack
> configuration then I'm not sure it would make sense upstream.

This is the normal behaviour of Smack, it's inherent.

Best regards
José
 
> > > I believe shm_open() is the right way. If you wanted to be even
> > > more modern, there is memfd_create syscall, but I don't we can
> > > generally assume it is always available yet.    
> > 
> > Does it really matter as you already provide a suitable solution? Go
> > directly to memfd_create if its better.  
> 
> memfd_create is a bit painful to use. I assume it still has no glibc
> wrapper. It was introduced in Linux 3.17 and is specific to Linux.
> OTOH, shm_open is a POSIX standard and we would need a shm_open path
> as a fallback to memfd_open.
> 
> 
> Thanks,
> pq