Providing shared buffer for applications within Smack environment

Tue Dec 12 18:27:53 UTC 2017

On Tue, 12 Dec 2017 18:29:30 +0100
Rafał Krypa <r.krypa at samsung.com> wrote:

> Hi,

Hi,

> On 2017-12-12 17:46, José Bollo wrote:
> > 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".  
> 
> 
> This statement about POSIX SHM and Smack is not true.
> You get a file descriptor from shm_open() and nothing stops you from
> calling fsetxattr(fd, XATTR_NAME_SMACK, ...) on it. Since Linux glibc
> implements POSIX SHM as files in /dev/shm/ tmpfs, this isn't really
> different than XDG_RUNTIMESHARED_DIR from Smack point of view.

I ignored that glibc has this implementation. In that case I was wrong.
Do you think that Smack settings of /dev/shm could help?

> Maybe
> you meant System V SHM segments, which indeed cannot be relabeled
> under Smack?

Yes I was thinking on shm_open of linux's "ipc" subsystem and shm
security hooks.

> By the way, we have had a similar problem in Tizen with services
> creating POSIX SHMs for applications, which then were unable to write
> to the shared memory. Smack prohibited write access between
> application label and service label. For such use case we have
> created our own wrapper for shm_open() taking additional argument -
> identifier of an app that is supposed to receive the memory. SHM
> backing file is being relabeled by privileged process to allow memory
> sharing. Check and see if this is relevant in your case:
> https://git.tizen.org/cgit/platform/core/security/security-manager/tree/src/include/app-runtime.h?h=tizen#n199
> https://git.tizen.org/cgit/platform/core/security/security-manager/tree/src/client/client-security-manager.cpp?h=tizen#n1639
> https://git.tizen.org/cgit/platform/core/security/security-manager/tree/src/common/service_impl.cpp?h=tizen#n1810