LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [GIT PULL] security subsystem: Tomoyo updates for v5.2
@ 2019-05-10 22:09 James Morris
  2019-05-11 14:38 ` Linus Torvalds
  2019-05-11 15:00 ` pr-tracker-bot
  0 siblings, 2 replies; 10+ messages in thread
From: James Morris @ 2019-05-10 22:09 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-security-module, linux-kernel

Please pull.

These patches include fixes to enable fuzz testing, and a fix for 
calculating whether a filesystem is user-modifiable.

The following changes since commit 1fb3b526df3bd7647e7854915ae6b22299408baf:

  Merge tag 'docs-5.2a' of git://git.lwn.net/linux (2019-05-10 13:24:53 -0400)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-tomoyo2

for you to fetch changes up to 4ad98ac46490d5f8441025930070eaf028cfd0f2:

  tomoyo: Don't emit WARNING: string while fuzzing testing. (2019-05-10 14:58:35 -0700)

----------------------------------------------------------------
Tetsuo Handa (4):
      tomoyo: Add a kernel config option for fuzzing testing.
      tomoyo: Check address length before reading address family
      tomoyo: Change pathname calculation for read-only filesystems.
      tomoyo: Don't emit WARNING: string while fuzzing testing.

 security/tomoyo/Kconfig    | 10 ++++++++++
 security/tomoyo/common.c   | 13 ++++++++++++-
 security/tomoyo/network.c  |  4 ++++
 security/tomoyo/realpath.c |  3 ++-
 security/tomoyo/util.c     |  2 ++
 5 files changed, 30 insertions(+), 2 deletions(-)

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [GIT PULL] security subsystem: Tomoyo updates for v5.2
  2019-05-10 22:09 [GIT PULL] security subsystem: Tomoyo updates for v5.2 James Morris
@ 2019-05-11 14:38 ` Linus Torvalds
  2019-05-11 18:13   ` Paul Moore
  2019-05-13 17:53   ` James Morris
  2019-05-11 15:00 ` pr-tracker-bot
  1 sibling, 2 replies; 10+ messages in thread
From: Linus Torvalds @ 2019-05-11 14:38 UTC (permalink / raw)
  To: James Morris; +Cc: LSM List, Linux List Kernel Mailing

On Fri, May 10, 2019 at 6:09 PM James Morris <jmorris@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.

                   Linus

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [GIT PULL] security subsystem: Tomoyo updates for v5.2
  2019-05-10 22:09 [GIT PULL] security subsystem: Tomoyo updates for v5.2 James Morris
  2019-05-11 14:38 ` Linus Torvalds
@ 2019-05-11 15:00 ` pr-tracker-bot
  1 sibling, 0 replies; 10+ messages in thread
From: pr-tracker-bot @ 2019-05-11 15:00 UTC (permalink / raw)
  To: James Morris; +Cc: Linus Torvalds, linux-security-module, linux-kernel

The pull request you sent on Sat, 11 May 2019 08:09:22 +1000 (AEST):

> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-tomoyo2

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c367dc8d0dd2a1e1ed9fdc2dd831053bdfdf0968

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [GIT PULL] security subsystem: Tomoyo updates for v5.2
  2019-05-11 14:38 ` Linus Torvalds
@ 2019-05-11 18:13   ` Paul Moore
  2019-05-11 22:08     ` Casey Schaufler
  2019-05-13 17:53   ` James Morris
  1 sibling, 1 reply; 10+ messages in thread
From: Paul Moore @ 2019-05-11 18:13 UTC (permalink / raw)
  To: Linus Torvalds, James Morris; +Cc: LSM List, Linux List Kernel Mailing

On Sat, May 11, 2019 at 10:38 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Fri, May 10, 2019 at 6:09 PM James Morris <jmorris@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

-- 
paul moore
www.paul-moore.com

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [GIT PULL] security subsystem: Tomoyo updates for v5.2
  2019-05-11 18:13   ` Paul Moore
@ 2019-05-11 22:08     ` Casey Schaufler
  2019-05-12 15:33       ` Paul Moore
  0 siblings, 1 reply; 10+ messages in thread
From: Casey Schaufler @ 2019-05-11 22:08 UTC (permalink / raw)
  To: Paul Moore, Linus Torvalds, James Morris
  Cc: LSM List, Linux List Kernel Mailing, casey

On 5/11/2019 11:13 AM, Paul Moore wrote:
> On Sat, May 11, 2019 at 10:38 AM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>> On Fri, May 10, 2019 at 6:09 PM James Morris <jmorris@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.

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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [GIT PULL] security subsystem: Tomoyo updates for v5.2
  2019-05-11 22:08     ` Casey Schaufler
@ 2019-05-12 15:33       ` Paul Moore
  2019-05-12 19:17         ` Linus Torvalds
  0 siblings, 1 reply; 10+ messages in thread
From: Paul Moore @ 2019-05-12 15:33 UTC (permalink / raw)
  To: Casey Schaufler
  Cc: Linus Torvalds, James Morris, LSM List, Linux List Kernel Mailing

On Sat, May 11, 2019 at 6:08 PM Casey Schaufler <casey@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@linux-foundation.org> wrote:
> >> On Fri, May 10, 2019 at 6:09 PM James Morris <jmorris@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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [GIT PULL] security subsystem: Tomoyo updates for v5.2
  2019-05-12 15:33       ` Paul Moore
@ 2019-05-12 19:17         ` Linus Torvalds
  2019-05-13 18:03           ` James Morris
  0 siblings, 1 reply; 10+ messages in thread
From: Linus Torvalds @ 2019-05-12 19:17 UTC (permalink / raw)
  To: Paul Moore
  Cc: Casey Schaufler, James Morris, LSM List, Linux List Kernel Mailing

On Sun, May 12, 2019 at 11:33 AM Paul Moore <paul@paul-moore.com> wrote:
>
> As far as I'm concerned, whatever makes it easier for Linus to consume
> the changes is the preferred path.

So for me it's not so much the pulling itself that ends up being a
problem, it's just that I want to feel like the pull request makes
sense, and I want to feel "safe" in pulling it.

The audit and selinux trees haven't had any issues that I can recall,
so that has worked fine. And it's been easier now that most of the
security layer things have been coming in separately, so it's easy for
me to see what's coming in, when it's in sane chunks that stand alone.
And then I also feel like _if_ there are problems in one area, it's
not affecting any other area the things are now. So if there's
something I want to look at a bit more, I might pull all the other
requests that I don't have any questions about, so that I can then
look more closely at the part I want to understand better.

I basically want to see pulls being "well-defined". That's both in the
area they affect, but also in the explanations for the pull request,
and preferably really also in the history (ie both the whole "starting
at a well-defined point", but also a "history is nice and clear", so I
like seeing topic branches and well-defined merges).

I guess it's kind of hard to explain, but it just gives me the warm
and fuzzies if I do a

    gitk ORIG_HEAD..

after having done a merge, and the history and merges I see "make sense".

Then I feel like even if there are problems with the code I pull, even
the problems will hopefully be well-defined. Sometimes that is
literally "ok, I'm bisecting some issue, but even before I've bisected
the whole way, I can see that it came in through a particular pull
request or two" because the changes came in through a few clearly
separated topic branch and it's clear which pull request it is even if
there are still a hundred more commits to bisect all the way..

Side note: this depends on the subsystem. When I pull huge subsystems
like networking from Davem or the big driver pulls from Greg, I don't
even look at the gitk history and ask myself "does this make sense",
because I have ceded that kind of worries over to Greg and Davem. The
history in their areas are their concern, and their subsystems are so
big that I don't expect them to make it make sense to me, if you see
what I mean. But if you want to see an area where you can see how
people have split up development in topic branches, you can look at my
"x86 merges", where I get separate pull requests for each topic
branch, and they all tend to be very clearly defined (but then there
might often a "misc leftovers" branch, or a couple of branches that
are just one or two commits).

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

Yeah, I think that's the sane model. And I think it's mostly been working.

             Linus

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [GIT PULL] security subsystem: Tomoyo updates for v5.2
  2019-05-11 14:38 ` Linus Torvalds
  2019-05-11 18:13   ` Paul Moore
@ 2019-05-13 17:53   ` James Morris
  2019-05-13 18:22     ` James Morris
  1 sibling, 1 reply; 10+ messages in thread
From: James Morris @ 2019-05-13 17:53 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: LSM List, Linux List Kernel Mailing

On Sat, 11 May 2019, Linus Torvalds wrote:

> On Fri, May 10, 2019 at 6:09 PM James Morris <jmorris@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.

These are just plain patches from the author, they were not part of any 
publicly accessible tree -- there's nowhere they could be merged from.

> We really need to find a different model for the security layer patches.
> 
>                    Linus
> 

-- 
James Morris
<jmorris@namei.org>


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [GIT PULL] security subsystem: Tomoyo updates for v5.2
  2019-05-12 19:17         ` Linus Torvalds
@ 2019-05-13 18:03           ` James Morris
  0 siblings, 0 replies; 10+ messages in thread
From: James Morris @ 2019-05-13 18:03 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Paul Moore, Casey Schaufler, LSM List, Linux List Kernel Mailing

On Sun, 12 May 2019, Linus Torvalds wrote:

> >     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.
> 
> Yeah, I think that's the sane model. And I think it's mostly been working.

New LSMs also need to be guided in, as part of a community effort.

-- 
James Morris
<jmorris@namei.org>


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [GIT PULL] security subsystem: Tomoyo updates for v5.2
  2019-05-13 17:53   ` James Morris
@ 2019-05-13 18:22     ` James Morris
  0 siblings, 0 replies; 10+ messages in thread
From: James Morris @ 2019-05-13 18:22 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: LSM List, Linux List Kernel Mailing

On Tue, 14 May 2019, James Morris wrote:

> On Sat, 11 May 2019, Linus Torvalds wrote:

> > 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.
> 
> These are just plain patches from the author, they were not part of any 
> publicly accessible tree -- there's nowhere they could be merged from.

The reason I created a new branch in this case was that the existing one 
had the same issue as the TPM branch. 

-- 
James Morris
<jmorris@namei.org>


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2019-05-13 18:22 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-10 22:09 [GIT PULL] security subsystem: Tomoyo updates for v5.2 James Morris
2019-05-11 14:38 ` Linus Torvalds
2019-05-11 18:13   ` Paul Moore
2019-05-11 22:08     ` Casey Schaufler
2019-05-12 15:33       ` Paul Moore
2019-05-12 19:17         ` Linus Torvalds
2019-05-13 18:03           ` James Morris
2019-05-13 17:53   ` James Morris
2019-05-13 18:22     ` James Morris
2019-05-11 15:00 ` pr-tracker-bot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).