linux-kernel - Re: [RFC v2 10/16] luo: luo

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALzav=eAWdADOyZHxCTF-eKwiYhw2ELj3mKJ+8uQY6sOf0Hmuw@mail.gmail.com>
Date: Wed, 28 May 2025 13:29:13 -0700
From: David Matlack <dmatlack@...gle.com>
To: Pasha Tatashin <pasha.tatashin@...een.com>
Cc: pratyush@...nel.org, jasonmiu@...gle.com, graf@...zon.com, 
	changyuanl@...gle.com, rppt@...nel.org, rientjes@...gle.com, corbet@....net, 
	rdunlap@...radead.org, ilpo.jarvinen@...ux.intel.com, kanie@...ux.alibaba.com, 
	ojeda@...nel.org, aliceryhl@...gle.com, masahiroy@...nel.org, 
	akpm@...ux-foundation.org, tj@...nel.org, yoann.congal@...le.fr, 
	mmaurer@...gle.com, roman.gushchin@...ux.dev, chenridong@...wei.com, 
	axboe@...nel.dk, mark.rutland@....com, jannh@...gle.com, 
	vincent.guittot@...aro.org, hannes@...xchg.org, dan.j.williams@...el.com, 
	david@...hat.com, joel.granados@...nel.org, rostedt@...dmis.org, 
	anna.schumaker@...cle.com, song@...nel.org, zhangguopeng@...inos.cn, 
	linux@...ssschuh.net, linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org, 
	linux-mm@...ck.org, gregkh@...uxfoundation.org, tglx@...utronix.de, 
	mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com, x86@...nel.org, 
	hpa@...or.com, rafael@...nel.org, dakr@...nel.org, 
	bartosz.golaszewski@...aro.org, cw00.choi@...sung.com, 
	myungjoo.ham@...sung.com, yesanishhere@...il.com, Jonathan.Cameron@...wei.com, 
	quic_zijuhu@...cinc.com, aleksander.lobakin@...el.com, ira.weiny@...el.com, 
	andriy.shevchenko@...ux.intel.com, leon@...nel.org, lukas@...ner.de, 
	bhelgaas@...gle.com, wagi@...nel.org, djeffery@...hat.com, 
	stuart.w.hayes@...il.com, ptyadav@...zon.de
Subject: Re: [RFC v2 10/16] luo: luo_ioctl: add ioctl interface

On Thu, May 15, 2025 at 11:23 AM Pasha Tatashin
<pasha.tatashin@...een.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.