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

[John Johansen <john.johansen@canonical.com>]

On 7/9/20 9:11 AM, Stephen Smalley wrote:
> On Wed, Jul 8, 2020 at 8:23 PM Casey Schaufler <casey@schaufler-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@chromium.org>
>> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
>> Cc: netdev@vger.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?
>