[CRIU] [PATCH v2] lsm: adds process attribute getter for Landlock

[Paul Moore]

On Tue, May 23, 2023 at 2:13 AM Jeff Xu <jeffxu at chromium.org> wrote:
> On Mon, May 22, 2023 at 12:56 PM Paul Moore <paul at paul-moore.com> wrote:
> > On Thu, May 18, 2023 at 5:26 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
> > > On 5/18/2023 1:45 PM, Shervin Oloumi wrote:
> > > > Adds a new getprocattr hook function to the Landlock LSM, which tracks
> > > > the landlocked state of the process. This is invoked when user-space
> > > > reads /proc/[pid]/attr/domain
> > >
> > > Please don't add a Landlock specific entry directly in the attr/
> > > directory. Add it only to attr/landlock.
> > >
> > > Also be aware that the LSM maintainer (Paul Moore) wants to move
> > > away from the /proc/.../attr interfaces in favor of a new system call,
> > > which is in review.
> >
> > What Casey said above.
> >
> > There is still some uncertainty around timing, and if we're perfectly
> > honest, acceptance of the new syscalls at the Linus level, but yes, I
> > would very much like to see the LSM infrastructure move away from
> > procfs and towards a syscall API.  Part of the reasoning is that the
> > current procfs API is ill-suited to handle the multiple, stacked LSMs
> > and the other part being the complexity of procfs in a namespaced
> > system.  If the syscall API is ultimately rejected, we will need to
> > revisit the idea of a procfs API, but even then I think we'll need to
> > make some changes to the current approach.
> >
> > As I believe we are in the latter stages of review for the syscall
> > API, perhaps you could take a look and ensure that the current
> > proposed API works for what you are envisioning with Landlock?
> >
> Which review/patch to look for the proposed API ?

See Casey's reply if you haven't already.  You can also find the LSM
list archived on lore.kernel.org; that is probably the best way to
track LSM development if you don't want to subscribe to the list.

* https://lore.kernel.org/linux-security-module

> I guess ChromeOS will need to backport to 5.10 when the proposal is accepted.

Maybe?  Distro specific backports aren't generally on-topic for the
upstream Linux mailing lists, especially large commercial distros with
plenty of developers to take care of things like that.

-- 
paul-moore.com