On 12/07/2023 13:08, Günther Noack wrote:
Hello!
On Sat, Jun 17, 2023 at 11:47:55AM +0200, Mickaël Salaün wrote:
We should also think about batch operations on FD (see the
close_range syscall), for instance to deny all IOCTLs on inherited
or received FDs.
Hm, you mean a landlock_fd_rights_limit_range() syscall to limit the
rights for an entire range of FDs?
I have to admit, I'm not familiar with the real-life use cases of
close_range(). In most programs I work with, it's difficult to reason
about their ordering once the program has really started to run. So I
imagine that close_range() is mostly used to "sanitize" the open file
descriptors at the start of main(), and you have a similar use case in
mind for this one as well?
If it's just about closing the range from 0 to 2, I'm not sure it's
worth adding a custom syscall. :)
The advantage of this kind of range is to efficiently manage all potential
FDs, and the main use case is to close (or change, see the flags) everything
*except" 0-2 (i.e. 3-~0), and then avoid a lot of (potentially useless)
syscalls.
The Landlock interface doesn't need to be a syscall. We could just add a new
rule type which could take a FD range and restrict them when calling
landlock_restrict_self(). Something like this:
struct landlock_fd_attr {
__u64 allowed_access;
__u32 first;
__u32 last;
}
FYI, regarding the idea of dropping rights on already-opened files:
I'm starting to have doubts about how feasible this is in practice.
The "obvious" approach is to just remove the access rights from the security
blob flags on the struct file.
But these opened "struct file"s might be shared with other processes already,
and mutating them in place would have undesired side effects on other processes.
For example, if brltty uses ioctls on the terminal and then one of the programs
running in that terminal drops ioctl rights on that open file, it would affect
brltty as well, because both the Landlocked program and brltty use the same
struct file.
It could be technically stored next to the file descriptor list, where the
close-on-exec flag is also stored, but that seems more cumbersome than I had
hoped. I don't have a good approach for that idea yet, so I'll drop it for now.
Indeed, as discussed in another thread (patch v9 network support), I now
think that file descriptors should not be touched nor restricted by
Landlock. Even if there are file *descriptions* and file descriptors,
Landlock should focus on what user space cannot already do (i.e. close
file descriptors). Already acquired file descriptors should be a concern
for user space sandboxers and the whole system/services.
Ideas are welcome. :)
—Günther
