All of lore.kernel.org
 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: [kernel-hardening] 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 */
>
> ...
>

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