netdev - Re: [PATCH v18 05/23] net: Prepare UDS for security module stacking

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: <8a5a243f-e991-ad55-0503-654cc2587133@canonical.com>
Date:   Thu, 9 Jul 2020 09:28:42 -0700
From:   John Johansen <john.johansen@...onical.com>
To:     Stephen Smalley <stephen.smalley.work@...il.com>,
        Casey Schaufler <casey@...aufler-ca.com>
Cc:     Casey Schaufler <casey.schaufler@...el.com>,
        James Morris <jmorris@...ei.org>,
        LSM List <linux-security-module@...r.kernel.org>,
        SElinux list <selinux@...r.kernel.org>,
        Kees Cook <keescook@...omium.org>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Paul Moore <paul@...l-moore.com>,
        Stephen Smalley <sds@...ho.nsa.gov>, netdev@...r.kernel.org
Subject: Re: [PATCH v18 05/23] net: Prepare UDS for security module stacking

On 7/9/20 9:11 AM, Stephen Smalley wrote:
> On Wed, Jul 8, 2020 at 8:23 PM Casey Schaufler <casey@...aufler-ca.com> wrote:
>>
>> Change the data used in UDS SO_PEERSEC processing from a
>> secid to a more general struct lsmblob. Update the
>> security_socket_getpeersec_dgram() interface to use the
>> lsmblob. There is a small amount of scaffolding code
>> that will come out when the security_secid_to_secctx()
>> code is brought in line with the lsmblob.
>>
>> The secid field of the unix_skb_parms structure has been
>> replaced with a pointer to an lsmblob structure, and the
>> lsmblob is allocated as needed. This is similar to how the
>> list of passed files is managed. While an lsmblob structure
>> will fit in the available space today, there is no guarantee
>> that the addition of other data to the unix_skb_parms or
>> support for additional security modules wouldn't exceed what
>> is available.
>>
>> Reviewed-by: Kees Cook <keescook@...omium.org>
>> Signed-off-by: Casey Schaufler <casey@...aufler-ca.com>
>> Cc: netdev@...r.kernel.org
>> ---
> 
>> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
>> index 3385a7a0b231..d246aefcf4da 100644
>> --- a/net/unix/af_unix.c
>> +++ b/net/unix/af_unix.c
>> @@ -138,17 +138,23 @@ static struct hlist_head *unix_sockets_unbound(void *addr)
>>  #ifdef CONFIG_SECURITY_NETWORK
>>  static void unix_get_secdata(struct scm_cookie *scm, struct sk_buff *skb)
>>  {
>> -       UNIXCB(skb).secid = scm->secid;
>> +       UNIXCB(skb).lsmdata = kmemdup(&scm->lsmblob, sizeof(scm->lsmblob),
>> +                                     GFP_KERNEL);
>>  }
>>
>>  static inline void unix_set_secdata(struct scm_cookie *scm, struct sk_buff *skb)
>>  {
>> -       scm->secid = UNIXCB(skb).secid;
>> +       if (likely(UNIXCB(skb).lsmdata))
>> +               scm->lsmblob = *(UNIXCB(skb).lsmdata);
>> +       else
>> +               lsmblob_init(&scm->lsmblob, 0);
>>  }
>>
>>  static inline bool unix_secdata_eq(struct scm_cookie *scm, struct sk_buff *skb)
>>  {
>> -       return (scm->secid == UNIXCB(skb).secid);
>> +       if (likely(UNIXCB(skb).lsmdata))
>> +               return lsmblob_equal(&scm->lsmblob, UNIXCB(skb).lsmdata);
>> +       return false;
>>  }
> 
> I don't think that this provides sensible behavior to userspace.  On a
> transient memory allocation failure, instead of returning an error to
> the sender and letting them handle it, this will just proceed with
> sending the message without its associated security information, and
> potentially split messages on arbitrary boundaries because it cannot
> tell whether the sender had the same security information.  I think
> you instead need to change unix_get_secdata() to return an error on
> allocation failure and propagate that up to the sender.  Not a fan of
> this change in general both due to extra overhead on this code path
> and potential for breakage on allocation failures.  I know it was
> motivated by paul's observation that we won't be able to fit many more
> secids into the cb but not sure we have to go there prematurely,
> especially absent its usage by upstream AA (no unix_stream_connect
> hook implementation upstream).  Also not sure how the whole bpf local

I'm not sure how premature it is, I am running late for 5.9 but would
like to land apparmor unix mediation in 5.10

> storage approach to supporting security modules (or at least bpf lsm)
> might reduce need for expanding these structures?
>