From: Eric Paris <eparis@redhat.com>
To: Richard Guy Briggs <rgb@redhat.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-audit@redhat.com
Cc: Kangkook Jee <aixer77@gmail.com>, Paul Moore <pmoore@redhat.com>,
Steve Grubb <sgrubb@redhat.com>
Subject: Re: [PATCH V2] audit: log 32-bit socketcalls
Date: Fri, 13 Jan 2017 09:42:23 -0500 [thread overview]
Message-ID: <1484318543.5300.1.camel@redhat.com> (raw)
In-Reply-To: <dd937da01da72da9277e44ed79abd1f4618c14c5.1484297765.git.rgb@redhat.com>
On Fri, 2017-01-13 at 04:51 -0500, Richard Guy Briggs wrote:
> 32-bit socketcalls were not being logged by audit on x86_64 systems.
> Log them. This is basically a duplicate of the call from
> net/socket.c:sys_socketcall(), but it addresses the impedance
> mismatch
> between 32-bit userspace process and 64-bit kernel audit.
>
> See: https://github.com/linux-audit/audit-kernel/issues/14
>
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
>
> --
> v2:
> Move work to audit_socketcall_compat() and use
> audit_dummy_context().
> ---
> include/linux/audit.h | 16 ++++++++++++++++
> net/compat.c | 15 +++++++++++++--
> 2 files changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index 9d4443f..43d8003 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -387,6 +387,18 @@ static inline int audit_socketcall(int nargs,
> unsigned long *args)
> return __audit_socketcall(nargs, args);
> return 0;
> }
> +static inline int audit_socketcall_compat(int nargs, u32 *args)
> +{
> + if (unlikely(!audit_dummy_context())) {
I've always hated these likely/unlikely. Mostly because I think they
are so often wrong. I believe this says that you compiled audit in but
you expect it to be explicitly disabled. While that is (recently) true
in Fedora I highly doubt that's true on the vast majority of systems
that have audit compiled in.
I think all of the likely/unlikely need to just be abandoned, but at
least don't add more? It certainly wouldn't be the first time I was
wrong, and I haven't profiled it. But the function would definitely
look better if coded
static inline int audit_socketcall_compat(int nargs, u32 *args)
{
if (audit_cummy_context()) {
return 0
}
int i;
unsigned long a[AUDITSC_ARGS];
[...]
}
> + int i;
> + unsigned long a[AUDITSC_ARGS];
> +
> + for (i=0; i<nargs; i++)
> + a[i] = (unsigned long)args[i];
> + return __audit_socketcall(nargs, a);
> + }
> + return 0;
> +}
> static inline int audit_sockaddr(int len, void *addr)
> {
> if (unlikely(!audit_dummy_context()))
> @@ -513,6 +525,10 @@ static inline int audit_socketcall(int nargs,
> unsigned long *args)
> {
> return 0;
> }
> +static inline int audit_socketcall_compat(int nargs, u32 *args)
> +{
> + return 0;
> +}
> static inline void audit_fd_pair(int fd1, int fd2)
> { }
> static inline int audit_sockaddr(int len, void *addr)
> diff --git a/net/compat.c b/net/compat.c
> index 1cd2ec0..f0404d4 100644
> --- a/net/compat.c
> +++ b/net/compat.c
> @@ -22,6 +22,7 @@
> #include <linux/filter.h>
> #include <linux/compat.h>
> #include <linux/security.h>
> +#include <linux/audit.h>
> #include <linux/export.h>
>
> #include <net/scm.h>
> @@ -781,14 +782,24 @@ COMPAT_SYSCALL_DEFINE5(recvmmsg, int, fd,
> struct compat_mmsghdr __user *, mmsg,
>
> COMPAT_SYSCALL_DEFINE2(socketcall, int, call, u32 __user *, args)
> {
> + unsigned int len;
> int ret;
> - u32 a[6];
> + u32 a[AUDITSC_ARGS];
> u32 a0, a1;
>
> if (call < SYS_SOCKET || call > SYS_SENDMMSG)
> return -EINVAL;
> - if (copy_from_user(a, args, nas[call]))
> + len = nas[call];
> + if (len > sizeof(a))
> + return -EINVAL;
> +
> + if (copy_from_user(a, args, len))
> return -EFAULT;
> +
> + ret = audit_socketcall_compat(len/sizeof(a[0]), a);
> + if (ret)
> + return ret;
> +
> a0 = a[0];
> a1 = a[1];
>
next prev parent reply other threads:[~2017-01-13 14:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-13 9:51 [PATCH V2] audit: log 32-bit socketcalls Richard Guy Briggs
2017-01-13 14:42 ` Eric Paris [this message]
2017-01-13 15:06 ` Richard Guy Briggs
2017-01-13 15:18 ` Eric Paris
2017-01-13 15:20 ` Richard Guy Briggs
2017-01-16 20:04 ` Paul Moore
2017-01-17 3:53 ` Richard Guy Briggs
2017-01-17 13:29 ` Paul Moore
2017-01-16 18:27 ` David Miller
2017-01-16 20:38 ` Paul Moore
2017-01-16 21:55 ` David Miller
2017-01-17 4:03 ` Richard Guy Briggs
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=1484318543.5300.1.camel@redhat.com \
--to=eparis@redhat.com \
--cc=aixer77@gmail.com \
--cc=linux-audit@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pmoore@redhat.com \
--cc=rgb@redhat.com \
--cc=sgrubb@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 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).