linux-kernel - Re: [GIT PULL] security subsystem: Tomoyo updates for v5.2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <24d602d2-a1a7-7b1e-9035-a2d732cd822b@schaufler-ca.com>
Date:   Sat, 11 May 2019 15:08:07 -0700
From:   Casey Schaufler <casey@...aufler-ca.com>
To:     Paul Moore <paul@...l-moore.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        James Morris <jmorris@...ei.org>
Cc:     LSM List <linux-security-module@...r.kernel.org>,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        casey@...aufler-ca.com
Subject: Re: [GIT PULL] security subsystem: Tomoyo updates for v5.2

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