On 2/27/2018 9:36 AM, Andy Lutomirski wrote: > On Tue, Feb 27, 2018 at 5:30 PM, Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: >> On 2/27/2018 8:39 AM, Andy Lutomirski wrote: >>> On Tue, Feb 27, 2018 at 5:32 AM, Alexei Starovoitov >>> <alexei.starovoitov@xxxxxxxxx> wrote: >>>> [ Snip ] >>> An earlier version of the patch set used the seccomp filter chain. >>> Mickaël, what exactly was wrong with that approach other than that the >>> seccomp() syscall was awkward for you to use? You could add a >>> seccomp_add_landlock_rule() syscall if you needed to. >>> >>> As a side comment, why is this an LSM at all, let alone a non-stacking >>> LSM? It would make a lot more sense to me to make Landlock depend on >>> having LSMs configured in but to call the landlock hooks directly from >>> the security_xyz() hooks. >> Please, no. It is my serious intention to have at least the >> infrastructure blob management in within a release or two, and >> I think that's all Landlock needs. The security_xyz() hooks are >> sufficiently hackish as it is without unnecessarily adding more >> special cases. >> >> > What do you mean by "infrastructure blob management"? Today each security module manages their own module specific data, for example inode->i_security and file->f_security. This prevents having two security modules that have inode or file data from being used at the same time, because they both need to manage those fields. Moving the management of the module specific data (aka "blobs") from the security modules to the module infrastructure will allow those modules to coexist. Restrictions apply, of course, but I don't think that Landlock uses any of the facilities that would have issues. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
