[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHC9VhQbr1zgyvzM9zB97+rzO-Rcy6CUt_3-54ED-SEanVWyRQ@mail.gmail.com>
Date: Thu, 20 Oct 2022 11:44:41 -0400
From: Paul Moore <paul@...l-moore.com>
To: Casey Schaufler <casey@...aufler-ca.com>
Cc: casey.schaufler@...el.com, linux-security-module@...r.kernel.org,
linux-audit@...hat.com, jmorris@...ei.org, selinux@...r.kernel.org,
keescook@...omium.org, john.johansen@...onical.com,
penguin-kernel@...ove.sakura.ne.jp, stephen.smalley.work@...il.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v38 06/39] LSM: lsm_self_attr syscall for LSM self attributes
On Tue, Sep 27, 2022 at 3:57 PM Casey Schaufler <casey@...aufler-ca.com> wrote:
>
> Create a system call lsm_self_attr() to provide the security
> module maintained attributes of the current process. Historically
> these attributes have been exposed to user space via entries in
> procfs under /proc/self/attr.
Hi Casey,
I had hoped to get to review these patches earlier this week, I know
you are very anxious to see something happen here, but unfortunately
that didn't work out and I'm now in a position of limited network
access and time for a bit. I will do my best to at least comment on
the new syscall related additions, but thankfully you've already
started to get some good comments from others so I'm hopeful that will
help you keep moving forward.
One comment I did want to make, and it's important: please separate
the LSM syscall patches from the LSM stacking patches. While the
stacking patches will obviously be dependent on the syscall patches,
the syscall patches should not be dependent on stacking. However, the
LSM syscall patches must be designed from the start to support
multiple, simultaneous LSMs.
Thanks.
--
paul-moore.com
Powered by blists - more mailing lists