On Mon, Dec 12, 2022 at 10:36 AM Paolo Abeni <pabeni@xxxxxxxxxx> 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
