linux-kernel - Re: [PATCH v4 14/19] LSM: Infrastructure management of the inode security

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: <6243a363-e15a-e3fe-37ce-fb4c0a150873@schaufler-ca.com>
Date:   Wed, 3 Oct 2018 21:49:06 -0700
From:   Casey Schaufler <casey@...aufler-ca.com>
To:     James Morris <jmorris@...ei.org>, Kees Cook <keescook@...omium.org>
Cc:     LSM <linux-security-module@...r.kernel.org>,
        SE Linux <selinux@...ho.nsa.gov>,
        LKLM <linux-kernel@...r.kernel.org>,
        John Johansen <john.johansen@...onical.com>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Paul Moore <paul@...l-moore.com>,
        Stephen Smalley <sds@...ho.nsa.gov>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        Alexey Dobriyan <adobriyan@...il.com>,
        Mickaël Salaün <mic@...ikod.net>,
        Salvatore Mesoraca <s.mesoraca16@...il.com>
Subject: Re: [PATCH v4 14/19] LSM: Infrastructure management of the inode
 security

On 10/3/2018 11:13 AM, James Morris wrote:
> On Fri, 21 Sep 2018, Kees Cook wrote:
>
>> On Fri, Sep 21, 2018 at 5:19 PM, Casey Schaufler <casey@...aufler-ca.com> wrote:
>>> + * lsm_early_inode - during initialization allocate a composite inode blob
>>> + * @inode: the inode that needs a blob
>>> + *
>>> + * Allocate the inode blob for all the modules if it's not already there
>>> + */
>>> +void lsm_early_inode(struct inode *inode)
>>> +{
>>> +       int rc;
>>> +
>>> +       if (inode == NULL)
>>> +               panic("%s: NULL inode.\n", __func__);
>>> +       if (inode->i_security != NULL)
>>> +               return;
>>> +       rc = lsm_inode_alloc(inode);
>>> +       if (rc)
>>> +               panic("%s: Early inode alloc failed.\n", __func__);
>>> +}
>> I'm still advising against using panic(), but I'll leave it up to James.
>>
> Calling panic() is not appropriate here. Perhaps if it was during 
> boot-time initialization of LSM infrastructure, but not on the fly.

Tetsuo's patch makes this an __init function. It's only for doing
init time stuff like root inode initialization during start-up.
If it fails the caller is going to have to panic. This came straight
out of the SELinux system initialization code. I could go back to
having each LSM do it's own panic, but that seems silly.

>
> Use a WARN_ONCE then propagate the error back and fail the operation.
>
>