On Tue, May 23, 2023 at 2:13 AM Jeff Xu <jeffxu@xxxxxxxxxxxx> wrote: > On Mon, May 22, 2023 at 12:56 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > On Thu, May 18, 2023 at 5:26 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> 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
