[PATCH mptcp-net] mptcp: fix LSM labeling for passive msk
Paul Moore
paul at paul-moore.com
Mon Dec 12 23:28:14 UTC 2022
On Mon, Dec 12, 2022 at 10:36 AM Paolo Abeni <pabeni at redhat.com> wrote:
> If the preferrede solution is via a new LSM hook I have no objections
> at all. I'm sorry to put another hook mainteinance on you.
Don't worry about it, sure there is a bit more code, but I think it's
a better approach than all of the alternatives we've attempted. I'd
rather have "better" than a hack ;)
> How do you propose to preceed? After quickly digging into the relevant
> LSM code, the only module I think I could handle in a reasonable
> timeframe is selinux. Hopefully the new hook implementation should be
> quite straight-forward for the relevant SME.
That's sounds reasonable to me. Our policy in LSM land is that you
should provide at least one LSM implementation when adding a new hook
(the BPF LSM doesn't count due to it's rather unique approach), so if
you can provide a SELinux implementation that should meet that
requirement. I'm also not sure that any of the other LSMs currently
claim support for MPTCP.
> I guess the patch[es] should target the LSM tree, as the change in the
> mptcp code should be a one-liner. On the flip side, that would likely
> lead to some merge conflict, as the mptcp protocol impl. is quite a
> moving target.
The LSM has also seen a lot of renewed activity lately. However, I
think the deciding factor is where the bulk of the code will live, and
with the vast majority of the code expected under security/, I think
it makes sense to merge this via the LSM tree. My general policy for
the LSM tree is to either base your patches of Linus' tree or the
lsm/next branch and I'll handle whatever merge conflicts arise at the
time of merging.
For reference, the current LSM tree can be found here:
* https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm.git
--
paul-moore.com
More information about the Linux-security-module-archive
mailing list