On 21/06/2023 01:44, Jeff Xu wrote:
On Sat, Jun 17, 2023 at 2:49 AM Mickaël Salaün <mic@xxxxxxxxxxx> 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
