linux-kernel - Re: [PATCH 0/4] security: Split out hook definitions into lsm_hook

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAMp4zn8o0giNY2m=5bmfFA5veKZrux=zYzL0Aaqd2xi0PsZ+bA@mail.gmail.com>
Date:   Sun, 1 Apr 2018 13:43:11 -0700
From:   Sargun Dhillon <sargun@...gun.me>
To:     Casey Schaufler <casey@...aufler-ca.com>
Cc:     LSM <linux-security-module@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Kees Cook <keescook@...omium.org>,
        Igor Stoppa <igor.stoppa@...wei.com>,
        James Morris <jmorris@...ei.org>
Subject: Re: [PATCH 0/4] security: Split out hook definitions into lsm_hook_types.h

On Sun, Apr 1, 2018 at 10:32 AM, Casey Schaufler <casey@...aufler-ca.com> wrote:
>
> On 4/1/2018 3:17 AM, Sargun Dhillon wrote:
> > This moves all of the LSM hooks type information into a separate file,
> > lsm_hook_types.h. This enables us to use this file, along with macros
> > to generate the security_hook_heads struct, as well as the security
> > hooks union without having to duplicate definitions.
> >
> > This will be useful for further datastructures which want to use
> > the set of security hooks in a completely unrolled way, along
> > with the type information there within.
>
> Can you explain what this patch set is trying to accomplish?
> I see no value. I see massive complexity. Why is this better
> than what is there now?
>

1) Reduce the total amount of code
2) In the process of implementing the loadable hooks stuff, I wanted
to add a few more unrolled datastructures, specifically around static
keys, and I realized I would have to write an entirely new
datastructure like the security heads. To me, rather than having to
touch 3 different parts of code in order to change something, it seems
nice to keep it centralized. Same with RCU.
3) Rather than call_int_hook, and call_void_hook, we could generate an
actual function definitions. I think that will be a bit cleaner, esp.
in the context of the 2nd set of hook patches.