netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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];
>  

  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).