All of lore.kernel.org
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: Kees Cook <keescook@chromium.org>
Cc: linux-kernel@vger.kernel.org, Eric Paris <eparis@redhat.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [PATCH] audit: always report seccomp violations
Date: Sun, 25 Mar 2012 11:47:21 -0700	[thread overview]
Message-ID: <4F6F6839.6020605@schaufler-ca.com> (raw)
In-Reply-To: <20120323233212.GA18484@www.outflux.net>

On 3/23/2012 4:32 PM, Kees Cook wrote:
> When a program violates its own seccomp rules, that is a pretty dire
> situation, and the audit message should always be reported (not just
> when there is already a rule active for the process).

Hmm. If the program is never going to violate its own
seccomp rules it seems sort of silly to have them in the
first place, doesn't it? Oh, I know that the expectation
of seccomp is that the application would only try something
you've disallowed if it gets compromised. Problem is that
Modern Programmers tend to rely very heavily on the opaque
behavior of APIs that they don't understand nor particularly
care if they understand. When assumptions are made about the
behavior of the API code, and the API code changes, as
occurs with amazing frequency on today's mobile devices,
there are going to be surprises. I would wager that the
modern frequency of API changes will result in this behavior
being very unpopular.

>
> This change makes the audit_seccomp() logic similar to audit_core_dumps()
> (it does not require an active context). Since core dumps are more
> common, they sit behind an "audit_enabled" test. Audit reports of seccomp
> failures should always be visible, and fall back to printk when auditd
> is not running.
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
>  include/linux/audit.h |    8 +-------
>  kernel/auditsc.c      |   11 +++++++++--
>  2 files changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index ed3ef19..596077f 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -463,7 +463,7 @@ extern void audit_putname(const char *name);
>  extern void __audit_inode(const char *name, const struct dentry *dentry);
>  extern void __audit_inode_child(const struct dentry *dentry,
>  				const struct inode *parent);
> -extern void __audit_seccomp(unsigned long syscall);
> +extern void audit_seccomp(unsigned long syscall);
>  extern void __audit_ptrace(struct task_struct *t);
>  
>  static inline int audit_dummy_context(void)
> @@ -508,12 +508,6 @@ static inline void audit_inode_child(const struct dentry *dentry,
>  }
>  void audit_core_dumps(long signr);
>  
> -static inline void audit_seccomp(unsigned long syscall)
> -{
> -	if (unlikely(!audit_dummy_context()))
> -		__audit_seccomp(syscall);
> -}
> -
>  static inline void audit_ptrace(struct task_struct *t)
>  {
>  	if (unlikely(!audit_dummy_context()))
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index af1de0f..a5caecd 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -2693,7 +2693,7 @@ static void audit_log_abend(struct audit_buffer *ab, char *reason, long signr)
>   * @signr: signal value
>   *
>   * If a process ends with a core dump, something fishy is going on and we
> - * should record the event for investigation.
> + * should record the event for investigation, if auditing is enabled.
>   */
>  void audit_core_dumps(long signr)
>  {
> @@ -2710,7 +2710,14 @@ void audit_core_dumps(long signr)
>  	audit_log_end(ab);
>  }
>  
> -void __audit_seccomp(unsigned long syscall)
> +/**
> + * audit_seccomp - record information about processes that violate seccomp
> + * @syscall: syscall number that triggered the seccomp violation
> + *
> + * If a process violates its own seccomp rules, something has gone very
> + * wrong, and this event should always be reported for investigation.
> + */
> +void audit_seccomp(unsigned long syscall)
>  {
>  	struct audit_buffer *ab;
>  


  reply	other threads:[~2012-03-25 18:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-23 23:32 [PATCH] audit: always report seccomp violations Kees Cook
2012-03-25 18:47 ` Casey Schaufler [this message]
2012-03-26 15:56   ` Kees Cook
2012-03-26 16:59     ` Casey Schaufler
2012-03-26 17:02       ` Kees Cook
2012-03-29 18:27         ` Kees Cook

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=4F6F6839.6020605@schaufler-ca.com \
    --to=casey@schaufler-ca.com \
    --cc=eparis@redhat.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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.