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] [day] [month] [year] [list]

Message-ID: <CAEjxPJ69FyBKO8YrDW9Pc8Urc0q2-8db6EgEO3fYnK9MLx+Y5Q@mail.gmail.com>
Date:   Thu, 9 Jul 2020 15:54:19 -0400
From:   Stephen Smalley <stephen.smalley.work@...il.com>
To:     John Johansen <john.johansen@...onical.com>
Cc:     Casey Schaufler <casey@...aufler-ca.com>,
        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 Thu, Jul 9, 2020 at 12:28 PM John Johansen
<john.johansen@...onical.com> wrote:
>
> 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

Sorry I think I mischaracterized the condition under which this
support needs to be stacked. It seems to only be needed if using
SO_PASSSEC and SCM_SECURITY (i.e. datagram labeling), not just for
unix mediation or SO_PEERSEC IIUC.  So not sure if that applies even
for downstream.