On 10/20/2022 8:44 AM, Paul Moore wrote:

On Tue, Sep 27, 2022 at 3:57 PM Casey Schaufler [off-list ref] wrote:

quoted

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.

Thanks. I just got back to work myself. Hopefully the comments will prove
useful. I'm just getting to them.

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.

OK. I will refactor into two patch sets. The first will be the syscalls
for getting the LSM attributes and the second will be the stacking changes.
The prctl() I proposed to set the "display" LSM will be in the second, as
it makes no sense to have without anything to change. I have not to date
included the SO_PEERCONTEXT that would be required for complete stacking.
Would you like to see that included in the syscall patches?

Thanks.

Thank you.