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.
Ideas are welcome. :)
—Günther
--
Sent using Mutt 🐕 Woof Woof
