linux-kernel - Re: [PATCH v1 06/11] landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS

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: <f8f5ef29-4446-8f19-08a3-b9e080855405@digikod.net>
Date:   Thu, 24 Mar 2022 11:31:32 +0100
From:   Mickaël Salaün <mic@...ikod.net>
To:     Paul Moore <paul@...l-moore.com>
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
Subject: Re: [PATCH v1 06/11] landlock: Add support for file reparenting with
 LANDLOCK_ACCESS_FS_REFER


On 17/03/2022 13:04, Mickaël Salaün wrote:
> 
> On 17/03/2022 02:26, Paul Moore wrote:

[...]

>>> @@ -269,16 +270,188 @@ static inline bool is_nouser_or_private(const 
>>> struct dentry *dentry)
>>>                           
>>> unlikely(IS_PRIVATE(d_backing_inode(dentry))));
>>>   }
>>>
>>> -static int check_access_path(const struct landlock_ruleset *const 
>>> domain,
>>> -               const struct path *const path,
>>> +static inline access_mask_t get_handled_accesses(
>>> +               const struct landlock_ruleset *const domain)
>>> +{
>>> +       access_mask_t access_dom = 0;
>>> +       unsigned long access_bit;
>>
>> Would it be better to declare @access_bit as an access_mask_t type?
>> You're not using any macros like for_each_set_bit() in this function
>> so I believe it should be safe.
> 
> Right, I'll change that.

Well, thinking about it again, access_bit is not an access mask but an 
index in such mask. access_mask_t gives enough space for such index but 
it is definitely not the right semantic. The best type should be size_t, 
but I prefer to stick to unsigned long (used for size_t anyway) for 
consistency with the other access_bit variable types. There is no need 
to use for_each_set_bit() here now but that could change, and I prefer 
to do my best to prevent future issues. ;)
Anyway, I guess the compiler can optimize such code.