linux-kernel - Re: [PATCH v5 23/23] integrity: Switch from rbtree to LSM-managed blob for integrity_iint

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: <9dc633d8-65a7-4b97-ab98-a21ada1d4ea5@schaufler-ca.com>
Date:   Wed, 13 Dec 2023 10:08:48 -0800
From:   Casey Schaufler <casey@...aufler-ca.com>
To:     Roberto Sassu <roberto.sassu@...weicloud.com>,
        Paul Moore <paul@...l-moore.com>, viro@...iv.linux.org.uk,
        brauner@...nel.org, chuck.lever@...cle.com, jlayton@...nel.org,
        neilb@...e.de, kolga@...app.com, Dai.Ngo@...cle.com,
        tom@...pey.com, jmorris@...ei.org, serge@...lyn.com,
        zohar@...ux.ibm.com, dmitry.kasatkin@...il.com,
        dhowells@...hat.com, jarkko@...nel.org,
        stephen.smalley.work@...il.com, eparis@...isplace.org,
        mic@...ikod.net
Cc:     linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-nfs@...r.kernel.org, linux-security-module@...r.kernel.org,
        linux-integrity@...r.kernel.org, keyrings@...r.kernel.org,
        selinux@...r.kernel.org, Roberto Sassu <roberto.sassu@...wei.com>,
        Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [PATCH v5 23/23] integrity: Switch from rbtree to LSM-managed
 blob for integrity_iint_cache

On 12/13/2023 2:45 AM, Roberto Sassu wrote:
> On 17.11.23 21:57, Paul Moore wrote:
>> On Nov  7, 2023 Roberto Sassu <roberto.sassu@...weicloud.com> wrote:
>>>
>>> ...
>>>
>>> diff --git a/security/integrity/iint.c b/security/integrity/iint.c
>>> index 882fde2a2607..a5edd3c70784 100644
>>> --- a/security/integrity/iint.c
>>> +++ b/security/integrity/iint.c
>>> @@ -231,6 +175,10 @@ static int __init integrity_lsm_init(void)
>>>       return 0;
>>>   }
>>>   +struct lsm_blob_sizes integrity_blob_sizes __ro_after_init = {
>>> +    .lbs_inode = sizeof(struct integrity_iint_cache *),
>>> +};
>>
>> I'll admit that I'm likely missing an important detail, but is there
>> a reason why you couldn't stash the integrity_iint_cache struct
>> directly in the inode's security blob instead of the pointer?  For
>> example:
>>
>>    struct lsm_blob_sizes ... = {
>>      .lbs_inode = sizeof(struct integrity_iint_cache),
>>    };
>>
>>    struct integrity_iint_cache *integrity_inode_get(inode)
>>    {
>>      if (unlikely(!inode->isecurity))
>>        return NULL;
>
> Ok, this caught my attention...
>
> I see that selinux_inode() has it, but smack_inode() doesn't.
>
> Some Smack code assumes that the inode security blob is always non-NULL:
>
> static void init_inode_smack(struct inode *inode, struct smack_known
> *skp)
> {
>     struct inode_smack *isp = smack_inode(inode);
>
>     isp->smk_inode = skp;
>     isp->smk_flags = 0;
> }
>
>
> Is that intended? Should I add the check?

Unless there's a case where inodes are created without calling
security_inode_alloc() there should never be an inode without a
security blob by the time you get to the Smack hook. That said,
people seem inclined to take all sorts of shortcuts and create
various "inodes" that aren't really inodes. I also see that SELinux
doesn't check the blob for cred or file structures. And that I
wrote the code in both cases.

Based on lack of bug reports for Smack on inodes and SELinux on
creds or files, It appears that the check is unnecessary. On the
other hand, it sure looks like good error detection hygiene. I
would be inclined to include the check in new code, but not get
in a panic about existing code.

>
> Thanks
>
> Roberto
>
>>      return inode->i_security + integrity_blob_sizes.lbs_inode;
>>    }
>>
>> -- 
>> paul-moore.com
>
>