[GIT PULL] security subsystem: Tomoyo updates for v5.2

[Paul Moore]

On Sat, May 11, 2019 at 6:08 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
> On 5/11/2019 11:13 AM, Paul Moore wrote:
> > On Sat, May 11, 2019 at 10:38 AM Linus Torvalds
> > <torvalds at linux-foundation.org> wrote:
> >> On Fri, May 10, 2019 at 6:09 PM James Morris <jmorris at namei.org> wrote:
> >>> These patches include fixes to enable fuzz testing, and a fix for
> >>> calculating whether a filesystem is user-modifiable.
> >> So now these have been very recently rebased (on top of a random
> >> merge-window "tree of the day" version) instead of having multiple
> >> merges.
> >>
> >> That makes the history cleaner, but has its own issues.
> >>
> >> We really need to find a different model for the security layer patches.
> >
> > If it helps, the process I use for the SELinux and audit trees is
> > documented below.  While it's far from perfect (I still don't like
> > basing the -next trees on -rcX releases) it has seemed to work
> > reasonably well for some time now.
> >
> > * https://github.com/SELinuxProject/selinux-kernel/blob/master/README.md
>
> On the whole this looks fine to me. I am less comfortable than Paul
> is regarding changes that happen elsewhere, so I would be more likely
> to base in the rc-1 than Paul. More developers test with SELinux than
> Smack. I am in the process of putting an appropriate GPG environment
> together for 5.3.

I share your concern about external changes outside the subsystem
breaking things; this doesn't happen all that often with the audit
tree, but it seems to happen every couple of releases with the SELinux
tree.  This is one of the reasons why I test linux/master +
selinux/next + audit/next every few days, if not more often (see link
below).  I've found this regular testing to be extremely helpful, and
if anyone is interested I'd be happy to help you get something similar
going.

* http://www.paul-moore.com/blog/d/2019/04/kernel_secnext_repo.html

FWIW, the reason I don't like basing against -rc1 (or any -rcX tag for
that matter) is that the -rcX releases tend to be buggier than the
"proper" releases.  However, in practice I find myself basing the
selinux/next and audit/next branches against -rc1 almost every release
now; the rate of change outside the subsystem trees is simply too
high.

> The LSM infrastructure work I've been doing should still go through
> James, as it has global implications.

As far as I'm concerned, whatever makes it easier for Linus to consume
the changes is the preferred path.  My guess is that you are right and
any *significant* changes to the LSM layer itself, e.g. security/*, is
best sent via James' tree.  For smaller changes to the LSM layer I
think it's okay if they go in via an individual LSM tree so long as
all the other LSMs agree-on/ack the changes; which pretty much fits
what we've been doing for some time now and it seems to work well
enough.

-- 
paul moore
www.paul-moore.com