On 2/27/2018 9:36 AM, Andy Lutomirski wrote:

On Tue, Feb 27, 2018 at 5:30 PM, Casey Schaufler [off-list ref] wrote:

quoted

On 2/27/2018 8:39 AM, Andy Lutomirski wrote:

quoted

On Tue, Feb 27, 2018 at 5:32 AM, Alexei Starovoitov
[off-list ref] wrote:

quoted

[ 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-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html