| Message ID | alpine.LRH.2.21.1905110801350.9392@namei.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [GIT,PULL] security subsystem: Tomoyo updates for v5.2 | expand |
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
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!
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 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.
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.
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
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 >
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.
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.
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(-)