On 10/20/2022 8:44 AM, Paul Moore wrote: > On Tue, Sep 27, 2022 at 3:57 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> 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. 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.
