Providing shared buffer for applications within Smack environment

[Rafał Krypa]

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.
Maybe you meant System V SHM segments, which indeed cannot be relabeled under Smack?

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