linux-kernel - Re: [PATCH 0/3] Introduce LSM-hook for socketpair(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] [day] [month] [year] [list]

Message-ID: <CANq1E4QgRUvG4WJ_XZoWpvegE-TRF5CddiSptNUFQkURJr5Znw@mail.gmail.com>
Date:   Fri, 4 May 2018 16:29:14 +0200
From:   David Herrmann <dh.herrmann@...il.com>
To:     James Morris <jmorris@...ei.org>
Cc:     Paul Moore <paul@...l-moore.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Tom Gundersen <teg@...m.no>,
        Stephen Smalley <sds@...ho.nsa.gov>, selinux@...ho.nsa.gov,
        LSM <linux-security-module@...r.kernel.org>,
        Eric Paris <eparis@...isplace.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        "David S. Miller" <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH 0/3] Introduce LSM-hook for socketpair(2)

Hey

On Wed, Apr 25, 2018 at 9:02 PM, James Morris <jmorris@...ei.org> wrote:
> On Wed, 25 Apr 2018, Paul Moore wrote:
>
>> On Wed, Apr 25, 2018 at 2:44 PM, James Morris <jmorris@...ei.org> wrote:
>> > On Mon, 23 Apr 2018, David Herrmann wrote:
>> >> This patch series tries to close this gap and makes both behave the
>> >> same. A new LSM-hook is added which allows LSMs to cache the correct
>> >> peer information on newly created socket-pairs.
>> >
>> > Looks okay to me.
>> >
>> > Once it's respun with the Smack backend and maybe the hook name change,
>> > I'll merge this unless DaveM wants it to go in via his networking tree.
>>
>> Note my objection to the hook placement in patch 2/3; I think we
>> should move the hook out of the AF_UNIX layer and up into the socket
>> layer.
>
> I vote for this as it maintains the intended abstraction of the socket
> API.

Sounds good, I changed it. I will send v2 shortly.

Thanks
David