Security updates for v4.15 and beyond

On 09/25/2017 06:32 AM, Paul Moore wrote:

On Mon, Sep 25, 2017 at 12:59 AM, James Morris [off-list ref] wrote:

quoted

On Sun, 24 Sep 2017, Casey Schaufler wrote:

quoted

On 9/23/2017 10:00 PM, James Morris wrote:

quoted

<snip>

I plan on maintaining a separate branch for TPM (and other security
subsystems) from now on.

Can you tell us how you expect this to work? I know
there was discussion about this at the Security Summit.
We need to get whatever needs doing lined up if we're
going to make 4.15 happen smoothly.

I'll post a more detailed and general update in a few days when I'm back
in Sydney, but briefly, send me a pull request against my next-general
branch, which replaces the 'next' branch.  I'll sync that to -rc2 after
this email.

I'll fetch your branch into my next-smack branch, which will track
next-general.

All of these subsystem branches and next-general will be merged into
next-testing, for use by Stephen Rothwell for linux-next, and any other
general testing which may be done.

When the merge window opens, I'll merge the subsystem branches into
next-for-linus for him to pull.  If all is going well, this will be the
same as next-testing.  If there are problems in any of the branches, they
can be left out of next-for-linus until they're resolved.

Linus can then pull from that to get everything at once, or pull individual
branches as he sees fit.

In summary: track my next-general branch instead of 'next', and your
workflow is otherwise unchanged.

How does that sound?

Considering Linus' comments about him preferring individual branches,
I'm questioning the value in going through the linux-security tree; at
least for the larger, frequently updated LSMs; there is likely still
value in terms of convenience for the smaller, more static pieces
(e.g. capabilities, Yama, etc.).  I know there is the argument about
cross-LSM changes, but I can speak from experience (the SELinux next
branch feeds directly into the linux-next tree) that this tends not to
be a large problem.  I worry more about breakage caused by failed
interactions with the network stack than I do with other LSMs.  Yes,
there is the stacking work, and that will definitely have an impact,
but I think we can all agree that changes like this are going to be
rather rare, and I think we can also agree that the stacking work is
going to require a good deal of cross-LSM coordination regardless of
how the trees are organized.

quoted

From what Linus has said, and done, during the last merge window, I

suspect the "next-for-linus" branch is a waste of time, he would
prefer to pull from the individual branches and if he is pulling from
the individual subsystem branches, why not just pull from the
individual subsystem trees?  Help me understand the value, because
right now all I can see is an extra hop and another place where things
could fail.  As for linux-next, last time I spoke to them about it
(which was admittedly many years ago) they preferred to pull directly
from the subsystem trees; I know SELinux feeds directly into
linux-next, and I believe a few other LSMs do the same.

I have to agree with Paul here, unless there are infrastructure
changes this feels like an extra hop. With next directly pulling
security (for infrastructure) and LSM changes merge conflicts will
show up there. At which point we are going to need to coordinate,
but these should be rare.

--
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