Re: [RFC v2 10/16] luo: luo_ioctl: add ioctl interface

[David Matlack <dmatlack@google.com>]

On Thu, May 15, 2025 at 11:23 AM Pasha Tatashin
<pasha.tatashin@soleen.com> wrote:
> +static int luo_open(struct inode *inodep, struct file *filep)
> +{
> +       if (!capable(CAP_SYS_ADMIN))
> +               return -EACCES;

It makes sense that LIVEUPDATE_IOCTL_EVENT* would require
CAP_SYS_ADMIN. But I think requiring it for LIVEUPDATE_IOCTL_FD* will
add a lot of complexity.

It would essentially require a central userspace process to mediate
all preserving/restoring of file descriptors across Live Update to
enforce security. If we need a central authority to enforce security,
I don't see why that authority can't just be the kernel or what the
industry gains by punting the problem to userspace. It seems like all
users of LUO are going to want the same security guarantees when it
comes to FDs: a FD preserved inside a given "security domain" should
not be accessible outside that domain.

One way to do this in the kernel would be to have the kernel hand out
Live Update security tokens (say, some large random number). Then
require userspace to pass in a security token when preserving an FD.
Userspace can then only restore or unpreserve an FD if it passes back
in the security token associated with the FD. Then it's just up to
each userspace process to remember their token across kexec, keep it
secret from other untrusted processes, and pass it back in when
recovering FDs.

All the kernel has to do is generate secure tokens, which I imagine
can't be that hard.