netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Will Drewry <wad@chromium.org>
Cc: linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	linux-arch@vger.kernel.org, linux-doc@vger.kernel.org,
	kernel-hardening@lists.openwall.com, netdev@vger.kernel.org,
	x86@kernel.org, arnd@arndb.de, davem@davemloft.net,
	hpa@zytor.com, mingo@redhat.com, oleg@redhat.com,
	peterz@infradead.org, rdunlap@xenotime.net,
	mcgrathr@chromium.org, tglx@linutronix.de, luto@mit.edu,
	eparis@redhat.com, serge.hallyn@canonical.com, djm@mindrot.org,
	scarybeasts@gmail.com, indan@nul.nu, pmoore@redhat.com,
	corbet@lwn.net, eric.dumazet@gmail.com, markus@chromium.org,
	coreyb@linux.vnet.ibm.com, keescook@chromium.org,
	jmorris@namei.org
Subject: Re: [PATCH v17 08/15] seccomp: add system call filtering using BPF
Date: Fri, 6 Apr 2012 13:23:30 -0700	[thread overview]
Message-ID: <20120406132330.457a05cf.akpm@linux-foundation.org> (raw)
In-Reply-To: <1333051320-30872-9-git-send-email-wad@chromium.org>

On Thu, 29 Mar 2012 15:01:53 -0500
Will Drewry <wad@chromium.org> wrote:

> [This patch depends on luto@mit.edu's no_new_privs patch:
>    https://lkml.org/lkml/2012/1/30/264
>  included in this series for ease of consumption.
> ]
> 
> This patch adds support for seccomp mode 2.  Mode 2 introduces the
> ability for unprivileged processes to install system call filtering
> policy expressed in terms of a Berkeley Packet Filter (BPF) program.
> This program will be evaluated in the kernel for each system call
> the task makes and computes a result based on data in the format
> of struct seccomp_data.
> 
> A filter program may be installed by calling:
>   struct sock_fprog fprog = { ... };
>   ...
>   prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, &fprog);
> 
> The return value of the filter program determines if the system call is
> allowed to proceed or denied.  If the first filter program installed
> allows prctl(2) calls, then the above call may be made repeatedly
> by a task to further reduce its access to the kernel.  All attached
> programs must be evaluated before a system call will be allowed to
> proceed.
> 
> Filter programs will be inherited across fork/clone and execve.
> However, if the task attaching the filter is unprivileged
> (!CAP_SYS_ADMIN) the no_new_privs bit will be set on the task.  This
> ensures that unprivileged tasks cannot attach filters that affect
> privileged tasks (e.g., setuid binary).
> 
> There are a number of benefits to this approach. A few of which are
> as follows:
> - BPF has been exposed to userland for a long time
> - BPF optimization (and JIT'ing) are well understood
> - Userland already knows its ABI: system call numbers and desired
>   arguments
> - No time-of-check-time-of-use vulnerable data accesses are possible.
> - system call arguments are loaded on access only to minimize copying
>   required for system call policy decisions.
> 
> Mode 2 support is restricted to architectures that enable
> HAVE_ARCH_SECCOMP_FILTER.  In this patch, the primary dependency is on
> syscall_get_arguments().  The full desired scope of this feature will
> add a few minor additional requirements expressed later in this series.
> Based on discussion, SECCOMP_RET_ERRNO and SECCOMP_RET_TRACE seem to be
> the desired additional functionality.
> 
> No architectures are enabled in this patch.
> 
>
> ...
>
> +/**
> + * struct seccomp_filter - container for seccomp BPF programs
> + *
> + * @usage: reference count to manage the object liftime.

i found a bug

> + *         get/put helpers should be used when accessing an instance
> + *         outside of a lifetime-guarded section.  In general, this
> + *         is only needed for handling filters shared across tasks.
> + * @prev: points to a previously installed, or inherited, filter
> + * @len: the number of instructions in the program
> + * @insns: the BPF program instructions to evaluate
> + *
> + * seccomp_filter objects are organized in a tree linked via the @prev
> + * pointer.  For any task, it appears to be a singly-linked list starting
> + * with current->seccomp.filter, the most recently attached or inherited filter.
> + * However, multiple filters may share a @prev node, by way of fork(), which
> + * results in a unidirectional tree existing in memory.  This is similar to
> + * how namespaces work.
> + *
> + * seccomp_filter objects should never be modified after being attached
> + * to a task_struct (other than @usage).
> + */
> +struct seccomp_filter {
> +	atomic_t usage;
> +	struct seccomp_filter *prev;
> +	unsigned short len;  /* Instruction count */
> +	struct sock_filter insns[];
> +};
> +
> +/* Limit any path through the tree to 256KB worth of instructions. */
> +#define MAX_INSNS_PER_PATH ((1 << 18) / sizeof(struct sock_filter))
> +
> +static void seccomp_filter_log_failure(int syscall)
> +{
> +	int compat = 0;
> +#ifdef CONFIG_COMPAT
> +	compat = is_compat_task();
> +#endif

hm, I'm surprised that we don't have a zero-returning implementation of
is_compat_task() when CONFIG_COMPAT=n.  Seems silly.  Blames Arnd.

> +	pr_info("%s[%d]: %ssystem call %d blocked at 0x%lx\n",
> +		current->comm, task_pid_nr(current),
> +		(compat ? "compat " : ""),
> +		syscall, KSTK_EIP(current));
> +}
> +
> +/**
> + * get_u32 - returns a u32 offset into data
> + * @data: a unsigned 64 bit value
> + * @index: 0 or 1 to return the first or second 32-bits
> + *
> + * This inline exists to hide the length of unsigned long.
> + * If a 32-bit unsigned long is passed in, it will be extended
> + * and the top 32-bits will be 0. If it is a 64-bit unsigned
> + * long, then whatever data is resident will be properly returned.
> + */
> +static inline u32 get_u32(u64 data, int index)
> +{
> +	return ((u32 *)&data)[index];
> +}

This seems utterly broken on big-endian machines.  If so: fix.  If not:
add comment explaining why?

>
> ...
>
> +/**
> + *	seccomp_chk_filter - verify seccomp filter code
> + *	@filter: filter to verify
> + *	@flen: length of filter
> + *
> + * Takes a previously checked filter (by sk_chk_filter) and
> + * redirects all filter code that loads struct sk_buff data
> + * and related data through seccomp_bpf_load.  It also
> + * enforces length and alignment checking of those loads.
> + *
> + * Returns 0 if the rule set is legal or -EINVAL if not.
> + */
> +static int seccomp_chk_filter(struct sock_filter *filter, unsigned int flen)
> +{
> +	int pc;
> +	for (pc = 0; pc < flen; pc++) {
> +		struct sock_filter *ftest = &filter[pc];
> +		u16 code = ftest->code;
> +		u32 k = ftest->k;
> +		switch (code) {

It's conventional to have a blank line between end-of-locals and
start-of-code.


> +		case BPF_S_LD_W_ABS:
> +			ftest->code = BPF_S_ANC_SECCOMP_LD_W;
> +			/* 32-bit aligned and not out of bounds. */
> +			if (k >= sizeof(struct seccomp_data) || k & 3)
> +				return -EINVAL;
>
> ...
>
> +static u32 seccomp_run_filters(int syscall)
> +{
> +	struct seccomp_filter *f;
> +	u32 ret = SECCOMP_RET_KILL;
> +	/*
> +	 * All filters are evaluated in order of youngest to oldest. The lowest
> +	 * BPF return value always takes priority.
> +	 */

The youngest-first design surprised me.  It wasn't mentioned at all in
the changelog.  Thinking about it, I guess it just doesn't matter.  But
some description of the reasons for and implications of this decision
for the uninitiated would be welcome.

> +	for (f = current->seccomp.filter; f; f = f->prev) {
> +		ret = sk_run_filter(NULL, f->insns);
> +		if (ret != SECCOMP_RET_ALLOW)
> +			break;
> +	}
> +	return ret;
> +}
> +
> +/**
> + * seccomp_attach_filter: Attaches a seccomp filter to current.
> + * @fprog: BPF program to install
> + *
> + * Returns 0 on success or an errno on failure.
> + */
> +static long seccomp_attach_filter(struct sock_fprog *fprog)
> +{
> +	struct seccomp_filter *filter;
> +	unsigned long fp_size = fprog->len * sizeof(struct sock_filter);
> +	unsigned long total_insns = fprog->len;
> +	long ret;
> +
> +	if (fprog->len == 0 || fprog->len > BPF_MAXINSNS)
> +		return -EINVAL;
> +
> +	for (filter = current->seccomp.filter; filter; filter = filter->prev)
> +		total_insns += filter->len + 4;  /* include a 4 instr penalty */

So tasks don't share filters?  We copy them by value at fork?  Do we do
this at vfork() too?

> +	if (total_insns > MAX_INSNS_PER_PATH)
> +		return -ENOMEM;
> +
> +	/*
> +	 * Installing a seccomp filter requires that the task have
> +	 * CAP_SYS_ADMIN in its namespace or be running with no_new_privs.
> +	 * This avoids scenarios where unprivileged tasks can affect the
> +	 * behavior of privileged children.
> +	 */
> +	if (!current->no_new_privs &&
> +	    security_capable_noaudit(current_cred(), current_user_ns(),
> +				     CAP_SYS_ADMIN) != 0)
> +		return -EACCES;
> +
> +	/* Allocate a new seccomp_filter */
> +	filter = kzalloc(sizeof(struct seccomp_filter) + fp_size, GFP_KERNEL);

I think this gives userspace an easy way of causing page allocation
failure warnings, by permitting large kmalloc() attempts.  Add
__GFP_NOWARN?

> +	if (!filter)
> +		return -ENOMEM;
> +	atomic_set(&filter->usage, 1);
> +	filter->len = fprog->len;
> +
> +	/* Copy the instructions from fprog. */
> +	ret = -EFAULT;
> +	if (copy_from_user(filter->insns, fprog->filter, fp_size))
> +		goto fail;
> +
> +	/* Check and rewrite the fprog via the skb checker */
> +	ret = sk_chk_filter(filter->insns, filter->len);
> +	if (ret)
> +		goto fail;
> +
> +	/* Check and rewrite the fprog for seccomp use */
> +	ret = seccomp_chk_filter(filter->insns, filter->len);

"check" is spelled "check"!

> +	if (ret)
> +		goto fail;
> +
> +	/*
> +	 * If there is an existing filter, make it the prev and don't drop its
> +	 * task reference.
> +	 */
> +	filter->prev = current->seccomp.filter;
> +	current->seccomp.filter = filter;
> +	return 0;
> +fail:
> +	kfree(filter);
> +	return ret;
> +}
> +
>
> ...
>
> +/* put_seccomp_filter - decrements the ref count of tsk->seccomp.filter */
> +void put_seccomp_filter(struct task_struct *tsk)
> +{
> +	struct seccomp_filter *orig = tsk->seccomp.filter;
> +	/* Clean up single-reference branches iteratively. */
> +	while (orig && atomic_dec_and_test(&orig->usage)) {
> +		struct seccomp_filter *freeme = orig;
> +		orig = orig->prev;
> +		kfree(freeme);
> +	}
> +}

So if one of the filters in the list has an elevated refcount, we bail
out on the remainder of the list.  Seems odd.

> +#endif	/* CONFIG_SECCOMP_FILTER */
>
> ...
>

  parent reply	other threads:[~2012-04-06 20:23 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-29 20:01 [PATCH v17 00/15] seccomp_filter: BPF-based syscall filtering Will Drewry
2012-03-29 20:01 ` [PATCH v17 01/15] Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs Will Drewry
2012-04-06 19:49   ` Andrew Morton
2012-04-06 19:55     ` Andy Lutomirski
2012-04-06 20:47     ` Markus Gutschke
2012-04-06 20:54       ` Andrew Lutomirski
2012-04-06 21:04         ` Markus Gutschke
2012-04-06 21:15           ` Andrew Lutomirski
2012-04-06 21:32             ` Markus Gutschke
2012-04-10 19:12     ` Will Drewry
     [not found]   ` <1333051320-30872-2-git-send-email-wad-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
2012-04-06 19:55     ` Andrew Morton
2012-04-06 20:01       ` Andrew Lutomirski
2012-04-06 20:28         ` Jonathan Corbet
2012-04-06 20:37           ` Andrew Lutomirski
2012-04-11 19:31           ` Michael Kerrisk (man-pages)
2012-04-12  0:15             ` Michael Kerrisk (man-pages)
2012-04-12  0:50             ` Andrew Lutomirski
2012-04-16 19:11             ` Rob Landley
2012-04-10 20:37         ` Rob Landley
2012-04-10 19:03       ` Will Drewry
2012-03-29 20:01 ` [PATCH v17 02/15] Fix apparmor for PR_{GET,SET}_NO_NEW_PRIVS Will Drewry
2012-03-29 20:01 ` [PATCH v17 03/15] sk_run_filter: add BPF_S_ANC_SECCOMP_LD_W Will Drewry
2012-03-29 20:01 ` [PATCH v17 04/15] net/compat.c,linux/filter.h: share compat_sock_fprog Will Drewry
2012-03-29 20:01 ` [PATCH v17 05/15] seccomp: kill the seccomp_t typedef Will Drewry
2012-03-29 20:01 ` [PATCH v17 06/15] arch/x86: add syscall_get_arch to syscall.h Will Drewry
2012-03-29 20:01 ` [PATCH v17 07/15] asm/syscall.h: add syscall_get_arch Will Drewry
2012-04-06 20:05   ` Andrew Morton
2012-04-09 19:24     ` Will Drewry
2012-03-29 20:01 ` [PATCH v17 08/15] seccomp: add system call filtering using BPF Will Drewry
2012-03-31  4:40   ` Vladimir Murzin
2012-03-31 18:14     ` Will Drewry
2012-04-06 20:23   ` Andrew Morton [this message]
2012-04-06 20:44     ` Kees Cook
2012-04-06 21:05       ` Andrew Morton
2012-04-06 21:06         ` H. Peter Anvin
2012-04-06 21:09           ` Andrew Morton
2012-04-08 18:22     ` Indan Zupancic
2012-04-09 19:59       ` Will Drewry
2012-04-10  9:48         ` James Morris
2012-04-10 20:00         ` Andrew Morton
2012-04-10 20:16           ` Will Drewry
2012-04-10 10:34       ` Eric Dumazet
2012-04-10 19:54       ` Andrew Morton
2012-04-10 20:15         ` Will Drewry
2012-03-29 20:01 ` [PATCH v17 09/15] seccomp: remove duplicated failure logging Will Drewry
2012-04-06 21:14   ` Andrew Morton
2012-04-09 19:26     ` Will Drewry
2012-04-09 19:32       ` Kees Cook
2012-04-09 19:33       ` Eric Paris
2012-04-09 19:39         ` [kernel-hardening] " Kees Cook
2012-03-29 20:01 ` [PATCH v17 10/15] seccomp: add SECCOMP_RET_ERRNO Will Drewry
2012-04-06 21:19   ` Andrew Morton
2012-04-09 19:19     ` Will Drewry
2012-03-29 20:01 ` [PATCH v17 11/15] signal, x86: add SIGSYS info and make it synchronous Will Drewry
2012-03-29 20:01 ` [PATCH v17 12/15] seccomp: Add SECCOMP_RET_TRAP Will Drewry
2012-03-29 20:01 ` [PATCH v17 13/15] ptrace,seccomp: Add PTRACE_SECCOMP support Will Drewry
2012-04-06 21:24   ` Andrew Morton
2012-04-09 19:38     ` Will Drewry
2012-03-29 20:01 ` [PATCH v17 14/15] x86: Enable HAVE_ARCH_SECCOMP_FILTER Will Drewry
2012-03-29 20:02 ` [PATCH v17 15/15] Documentation: prctl/seccomp_filter Will Drewry
2012-04-06 21:26   ` Andrew Morton
2012-04-09 19:46     ` Will Drewry
2012-04-09 20:47       ` Markus Gutschke
2012-04-09 20:58         ` Ryan Ware
2012-04-09 22:47           ` Will Drewry
2012-04-10 17:49             ` Ryan Ware
2012-03-29 23:11 ` [PATCH v17 00/15] seccomp_filter: BPF-based syscall filtering James Morris
2012-04-06 21:28   ` Andrew Morton
2012-04-09  3:48     ` James Morris

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=20120406132330.457a05cf.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=corbet@lwn.net \
    --cc=coreyb@linux.vnet.ibm.com \
    --cc=davem@davemloft.net \
    --cc=djm@mindrot.org \
    --cc=eparis@redhat.com \
    --cc=eric.dumazet@gmail.com \
    --cc=hpa@zytor.com \
    --cc=indan@nul.nu \
    --cc=jmorris@namei.org \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=luto@mit.edu \
    --cc=markus@chromium.org \
    --cc=mcgrathr@chromium.org \
    --cc=mingo@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=pmoore@redhat.com \
    --cc=rdunlap@xenotime.net \
    --cc=scarybeasts@gmail.com \
    --cc=serge.hallyn@canonical.com \
    --cc=tglx@linutronix.de \
    --cc=wad@chromium.org \
    --cc=x86@kernel.org \
    /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).