On Thu, Jul 9, 2020 at 12:28 PM John Johansen
<john.johan...@canonical.com> wrote:
>
> 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
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.
