[RFC 0/4] Landlock: ioctl support

[Mickaël Salaün]

On 21/06/2023 01:44, Jeff Xu wrote:
> On Sat, Jun 17, 2023 at 2:49 AM Mickaël Salaün <mic at digikod.net> wrote:
>>
>>
>> On 24/05/2023 23:43, Jeff Xu wrote:
>>> Sorry for the late reply.
>>>>
>>>> (Looking in the direction of Jeff Xu, who has inquired about Landlock
>>>> for Chromium in the past -- do you happen to know in which ways you'd
>>>> want to restrict ioctls, if you have that need? :))
>>>>
>>>
>>> Regarding this patch, here is some feedback from ChromeOS:
>>>    - In the short term: we are looking to integrate Landlock into our
>>> sandboxer, so the ability to restrict to a specific device is huge.
>>> - Fundamentally though, in the effort of bringing process expected
>>> behaviour closest to allowed behaviour, the ability to speak of
>>> ioctl() path access in Landlock would be huge -- at least we can
>>> continue to enumerate in policy what processes are allowed to do, even
>>> if we still lack the ability to restrict individual ioctl commands for
>>> a specific device node.
>>
>> Thanks for the feedback!
>>
>>>
>>> Regarding medium term:
>>> My thoughts are, from software architecture point of view, it would be
>>> nice to think in planes: i.e. Data plane / Control plane/ Signaling
>>> Plane/Normal User Plane/Privileged User Plane. Let the application
>>> define its planes, and assign operations to them. Landlock provides
>>> data structure and syscall to construct the planes.
>>
>> I'm not sure to follow this plane thing. Could you give examples for
>> these planes applied to Landlock?
>>
> The idea is probably along the same lines as yours: let user space
> define/categorize ioctls.  For example, for a camera driver, users can
> define two planes - control plane: setup parameters of lens, data
> plane: setup data buffers for data transfer and do start/stop (I'm
> just making up the example since I don't really know the camera
> driver).
> 
> The idea is for Landlock to provide a mechanism to let user space to
> divide/assign ioctls to different planes, such that the user space
> processes can set/define security boundaries according to the plane it
> is on.

Right, we're on the same track. :)


> 
>>
>>>
>>> However, one thing I'm not sure is the third arg from ioctl:
>>> int ioctl(int fd, unsigned long request, ...);
>>> Is it possible for the driver to use the same request id, then put
>>> whatever into the third arg ? how to deal with that effectively ?
>>
>> I'm not sure about the value of all the arguments (except the command
>> one) vs. the complexity to filter them, but we could discuss that when
>> we'll reach this step.
>>
>>>
>>> For real world user cases, Dmitry Torokhov (added to list) can help.
>>
>> Yes please!
>>
> ya,  it will help with the design if there is a real world scenario to study.

I'll get internal requirements too.


> 
>>>
>>> PS: There is also lwn article about SELinux implementation of ioctl: [1]
>>> [1] https://lwn.net/Articles/428140/
>>
>> Thanks for the pointer, this shows how complex this IOCTL access control
>> is. For Landlock, I'd like to provide the minimal required features to
>> enable user space to define their own rules, which means to let user
>> space (and especially libraries) to identify useful or potentially
>> harmful IOCTLs.
>>
> Yes. That makes sense.
> 
>>>
>>> Thanks!
>>> -Jeff Xu