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