From: Paul Moore <paul@paul-moore.com>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: Stephen Smalley <stephen.smalley.work@gmail.com>,
Eric Paris <eparis@parisplace.org>,
selinux@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
syzkaller <syzkaller@googlegroups.com>,
Willem de Bruijn <willemb@google.com>
Subject: Re: selinux_netlink_send changes program behavior
Date: Fri, 24 Apr 2020 17:51:42 -0400 [thread overview]
Message-ID: <CAHC9VhQs6eJpX4oMrhBiDap-HhEsBBgmYWEou=ZH60YiA__T7w@mail.gmail.com> (raw)
In-Reply-To: <CACT4Y+YTi4JCFRqOB9rgA22S+6xxTo87X41hj6Tdfro8K3ef7g@mail.gmail.com>
On Fri, Apr 24, 2020 at 4:27 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> Hi SELinux maintainers,
>
> We've hit a case where a developer wasn't able to reproduce a kernel
> bug, it turned out to be a difference in behavior between SELinux and
> non-SELinux kernels.
> Condensed version: a program does sendmmsg on netlink socket with 2
> mmsghdr's, first is completely empty/zeros, second contains some
> actual payload. Without SELinux the first mmsghdr is treated as no-op
> and the kernel processes the second one (triggers bug). However the
> SELinux hook does:
>
> static int selinux_netlink_send(struct sock *sk, struct sk_buff *skb)
> {
> if (skb->len < NLMSG_HDRLEN) {
> err = -EINVAL;
> goto out;
> }
>
> and fails processing on the first empty mmsghdr (does not happen
> without SELinux).
>
> Is this difference in behavior intentional/acceptable/should be fixed?
From a practical perspective, SELinux is always going to need to do a
length check as it needs to peek into the netlink message header for
the message type so it can map that to the associated SELinux
permissions. So in that sense, the behavior is intentional and
desired; however from a bug-for-bug compatibility perspective ... not
so much.
Ultimately, my it's-Friday-and-it's-been-a-long-week-ending-in-a-long-day
thought is that this was a buggy operation to begin with and the bug
was just caught in different parts of the kernel, depending on how it
was configured. It may not be ideal, but I can think of worse things
(and arguably SELinux is doing the Right Thing).
--
paul moore
www.paul-moore.com
next prev parent reply other threads:[~2020-04-24 21:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-24 8:27 selinux_netlink_send changes program behavior Dmitry Vyukov
2020-04-24 21:51 ` Paul Moore [this message]
2020-04-25 5:14 ` Dmitry Vyukov
2020-04-25 11:42 ` Paul Moore
2020-04-25 12:00 ` Dmitry Vyukov
2020-04-28 1:53 ` Paul Moore
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHC9VhQs6eJpX4oMrhBiDap-HhEsBBgmYWEou=ZH60YiA__T7w@mail.gmail.com' \
--to=paul@paul-moore.com \
--cc=dvyukov@google.com \
--cc=eparis@parisplace.org \
--cc=linux-kernel@vger.kernel.org \
--cc=selinux@vger.kernel.org \
--cc=stephen.smalley.work@gmail.com \
--cc=syzkaller@googlegroups.com \
--cc=willemb@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).