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. > > > > > 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. > > > > 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
