From: Steve Grubb <sgrubb@redhat.com>
To: linux-audit@redhat.com
Cc: Richard Guy Briggs <rgb@redhat.com>
Subject: Re: [PATCH] audit: check the length of userspace generated audit records
Date: Tue, 21 Apr 2020 08:48:05 -0400 [thread overview]
Message-ID: <4619720.NsCMrGOoMo@x2> (raw)
In-Reply-To: <20200421001805.imgllrwuir7i4ry7@madcap2.tricolour.ca>
On Monday, April 20, 2020 8:18:06 PM EDT Richard Guy Briggs wrote:
> On 2020-04-20 17:56, Lenny Bruzenak wrote:
> > On 4/20/20 5:29 PM, Paul Moore wrote:
> > > On Mon, Apr 20, 2020 at 5:56 PM Richard Guy Briggs<rgb@redhat.com>
wrote:
> > > > On 2020-04-20 17:36, Paul Moore wrote:
> > > > > Commit 756125289285 ("audit: always check the netlink payload
> > > > > length
> > > > > in audit_receive_msg()") fixed a number of missing message length
> > > > > checks, but forgot to check the length of userspace generated audit
> > > > > records. The good news is that you need CAP_AUDIT_WRITE to submit
> > > > > userspace audit records, which is generally only given to trusted
> > > > > processes, so the impact should be limited.
> > > > >
> > > > > Cc:stable@vger.kernel.org
> > > > > Fixes: 756125289285 ("audit: always check the netlink payload
> > > > > length in audit_receive_msg()")
> > > > > Reported-by:syzbot+49e69b4d71a420ceda3e@syzkaller.appspotmail.com
> > > > > Signed-off-by: Paul Moore<paul@paul-moore.com>
> > > > > ---
> > > > >
> > > > > kernel/audit.c | 3 +++
> > > > > 1 file changed, 3 insertions(+)
> > > > >
> > > > > diff --git a/kernel/audit.c b/kernel/audit.c
> > > > > index b69c8b460341..87f31bf1f0a0 100644
> > > > > --- a/kernel/audit.c
> > > > > +++ b/kernel/audit.c
> > > > > @@ -1326,6 +1326,9 @@ static int audit_receive_msg(struct sk_buff
> > > > > *skb, struct nlmsghdr *nlh)> > > >
> > > > > case AUDIT_FIRST_USER_MSG2 ... AUDIT_LAST_USER_MSG2:
> > > > > if (!audit_enabled && msg_type != AUDIT_USER_AVC)
> > > > >
> > > > > return 0;
> > > > >
> > > > > + /* exit early if there isn't at least one character
> > > > > to print */ + if (data_len < 2)
> > > > > + return -EINVAL;
> > > >
> > > > Don't we want to issue the record even if the message is empty? If a
> > > > len of 1 is passed in, it will properly set str[0] = '\0' and str
> > > > points
> > > > to a location with a null that prints nothing between the single
> > > > quotes
> > > > of "msg=''". So, I think that should be "if (data_len < 1)".
> > > >
> > > > Am I missing something?
> > >
> > > I've got no problem with allowing an empty message so long as there is
> > > a valid use for such a message. Can anyone think of a valid reason
> > > for having an empty userspace generated record?
> >
> > Not really. Using the libaudit interface(s), even if an empty message
> > string is sent, and handled in the lib call(s), I believe it will have
> > minimum contextual info, e.g. "exe=... hostname=... ", etc.
> >
> > I can't think of a valid reason myself, assuming IIUC.
>
> But even with an empty message, there is still pid, uid, auid, ses, subj
> added by the kernel with its own message type. I could see a valid type
> of user message created that has no need for any of those fields added
> by audit_log_user_message(), calling audit_send_user_message() directly
> (but mind you, it appears to be deprecated to call it directly).
There is no valid reason. Even allowing just 1 character is also invalid and
a waste of disk space. But I guess you need to draw the line somewhere.
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
next prev parent reply other threads:[~2020-04-21 12:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-20 21:36 [PATCH] audit: check the length of userspace generated audit records Paul Moore
2020-04-20 21:56 ` Richard Guy Briggs
2020-04-20 23:29 ` Paul Moore
2020-04-20 23:56 ` Lenny Bruzenak
2020-04-21 0:18 ` Richard Guy Briggs
2020-04-21 12:48 ` Steve Grubb [this message]
2020-04-21 21:24 ` 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=4619720.NsCMrGOoMo@x2 \
--to=sgrubb@redhat.com \
--cc=linux-audit@redhat.com \
--cc=rgb@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.