linux-kernel - Re: [PATCH v1 01/11] landlock: Define access_mask_t to enforce a consistent access mask size

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: <CAHC9VhRhYbxyBK39uRRpXF9o-Yf-yMwWRvsE15wJnZr3-dexMA@mail.gmail.com>
Date:   Thu, 17 Mar 2022 17:31:51 -0400
From:   Paul Moore <paul@...l-moore.com>
To:     Mickaël Salaün <mic@...ikod.net>
Cc:     James Morris <jmorris@...ei.org>,
        "Serge E . Hallyn" <serge@...lyn.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Jann Horn <jannh@...gle.com>,
        Kees Cook <keescook@...omium.org>,
        Konstantin Meskhidze <konstantin.meskhidze@...wei.com>,
        Shuah Khan <shuah@...nel.org>, linux-doc@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        Mickaël Salaün <mic@...ux.microsoft.com>
Subject: Re: [PATCH v1 01/11] landlock: Define access_mask_t to enforce a
 consistent access mask size

On Thu, Mar 17, 2022 at 4:35 AM Mickaël Salaün <mic@...ikod.net> wrote:
> On 17/03/2022 02:26, Paul Moore wrote:
> > On Mon, Feb 21, 2022 at 4:15 PM Mickaël Salaün <mic@...ikod.net> wrote:
> >>
> >> From: Mickaël Salaün <mic@...ux.microsoft.com>
> >>
> >> Create and use the access_mask_t typedef to enforce a consistent access
> >> mask size and uniformly use a 16-bits type.  This will helps transition
> >> to a 32-bits value one day.
> >>
> >> Add a build check to make sure all (filesystem) access rights fit in.
> >> This will be extended with a following commit.
> >>
> >> Signed-off-by: Mickaël Salaün <mic@...ux.microsoft.com>
> >> Link: https://lore.kernel.org/r/20220221212522.320243-2-mic@digikod.net
> >> ---
> >>   security/landlock/fs.c      | 19 ++++++++++---------
> >>   security/landlock/fs.h      |  2 +-
> >>   security/landlock/limits.h  |  2 ++
> >>   security/landlock/ruleset.c |  6 ++++--
> >>   security/landlock/ruleset.h | 17 +++++++++++++----
> >>   5 files changed, 30 insertions(+), 16 deletions(-)

...

> >> diff --git a/security/landlock/limits.h b/security/landlock/limits.h
> >> index 2a0a1095ee27..458d1de32ed5 100644
> >> --- a/security/landlock/limits.h
> >> +++ b/security/landlock/limits.h
> >> @@ -9,6 +9,7 @@
> >>   #ifndef _SECURITY_LANDLOCK_LIMITS_H
> >>   #define _SECURITY_LANDLOCK_LIMITS_H
> >>
> >> +#include <linux/bitops.h>
> >>   #include <linux/limits.h>
> >>   #include <uapi/linux/landlock.h>
> >>
> >> @@ -17,5 +18,6 @@
> >>
> >>   #define LANDLOCK_LAST_ACCESS_FS                LANDLOCK_ACCESS_FS_MAKE_SYM
> >>   #define LANDLOCK_MASK_ACCESS_FS                ((LANDLOCK_LAST_ACCESS_FS << 1) - 1)
> >> +#define LANDLOCK_NUM_ACCESS_FS         __const_hweight64(LANDLOCK_MASK_ACCESS_FS)
> >
> > The line above, and the static_assert() in ruleset.h are clever.  I'll
> > admit I didn't even know the hweightX() macros existed until looking
> > at this code :)
> >
> > However, the LANDLOCK_NUM_ACCESS_FS is never really going to be used
> > outside the static_assert() in ruleset.h is it?  I wonder if it would
> > be better to skip the extra macro and rewrite the static_assert like
> > this:
> >
> > static_assert(BITS_PER_TYPE(access_mask_t) >=
> > __const_hweight64(LANDLOCK_MASK_ACCESS_FS));
> >
> > If not, I might suggest changing LANDLOCK_NUM_ACCESS_FS to
> > LANDLOCK_BITS_ACCESS_FS or something similar.
>
> I declared LANDLOCK_NUM_ACCESS_FS in this patch to be able to have the
> static_assert() here and ease the review, but LANDLOCK_NUM_ACCESS_FS is
> really used in patch 6/11 to define an array size:
> get_handled_acceses(), init_layer_masks(), is_superset(),
> check_access_path_dual()…

I wrote my comments as I was working my way through the patchset and
didn't think to go back and check this when I hit patch 6/11 :)

Looks good to me, sorry for the noise.

Reviewed-by: Paul Moore <paul@...l-moore.com>

-- 
paul-moore.com