lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 3 Feb 2012 15:14:52 -0800
From:	Will Drewry <wad@...omium.org>
To:	"Serge E. Hallyn" <serge.hallyn@...onical.com>
Cc:	linux-kernel@...r.kernel.org, keescook@...omium.org,
	john.johansen@...onical.com, coreyb@...ux.vnet.ibm.com,
	pmoore@...hat.com, eparis@...hat.com, djm@...drot.org,
	torvalds@...ux-foundation.org, segoon@...nwall.com,
	rostedt@...dmis.org, jmorris@...ei.org, scarybeasts@...il.com,
	avi@...hat.com, penberg@...helsinki.fi, viro@...iv.linux.org.uk,
	luto@....edu, mingo@...e.hu, akpm@...ux-foundation.org,
	khilman@...com, borislav.petkov@....com, amwang@...hat.com,
	oleg@...hat.com, ak@...ux.intel.com, eric.dumazet@...il.com,
	gregkh@...e.de, dhowells@...hat.com, daniel.lezcano@...e.fr,
	linux-fsdevel@...r.kernel.org,
	linux-security-module@...r.kernel.org, olofj@...omium.org,
	mhalcrow@...gle.com, dlaor@...hat.com, corbet@....net,
	alan@...rguk.ukuu.org.uk, indan@....nu, mcgrathr@...omium.org
Subject: Re: [PATCH v6 2/3] seccomp_filters: system call filtering using BPF

On Thu, Feb 2, 2012 at 7:32 AM, Serge E. Hallyn
<serge.hallyn@...onical.com> wrote:
> Quoting Will Drewry (wad@...omium.org):
>> [This patch depends on luto@....edu's no_new_privs patch:
>>  https://lkml.org/lkml/2012/1/12/446
>> ]
>>
>> This patch adds support for seccomp mode 2.  This mode enables dynamic
>> enforcement of system call filtering policy in the kernel as specified
>> by a userland task.  The policy is expressed in terms of a Berkeley
>> Packet Filter program, as is used for userland-exposed socket filtering.
>> Instead of network data, the BPF program is evaluated over struct
>> seccomp_filter_data at the time of the system call.
>>
>> A filter program may be installed by a userland task by calling
>>   prctl(PR_ATTACH_SECCOMP_FILTER, &fprog);
>> where fprog is of type struct sock_fprog.
>>
>> If the first filter program allows subsequent prctl(2) calls, then
>> additional filter programs may be attached.  All attached programs
>> must be evaluated before a system call will be allowed to proceed.
>>
>> To avoid CONFIG_COMPAT related landmines, once a filter program is
>> installed using specific is_compat_task() value, it is not allowed to
>> make system calls using the alternate entry point.
>>
>> Filter programs will be inherited across fork/clone and execve, however
>> the installation of filters must be preceded by setting 'no_new_privs'
>> to ensure that unprivileged tasks cannot attach filters that affect
>> privileged tasks (e.g., setuid binary).  Tasks with CAP_SYS_ADMIN
>> in their namespace may install inheritable filters without setting
>> the no_new_privs bit.
>>
>> 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.
>> - 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 demand only to minimize copying
>>   required for system call number-only policy decisions.
>>
>> This patch includes its own BPF evaluator, but relies on the
>> net/core/filter.c BPF checking code.  It is possible to share
>> evaluators, but the performance sensitive nature of the network
>> filtering path makes it an iterative optimization which (I think :) can
>> be tackled separately via separate patchsets. (And at some point sharing
>> BPF JIT code!)
>>
>>  v6: - fix memory leak on attach compat check failure
>>      - require no_new_privs || CAP_SYS_ADMIN prior to filter
>>        installation. (luto@....edu)
>>      - s/seccomp_struct_/seccomp_/ for macros/functions
>>        (amwang@...hat.com)
>>      - cleaned up Kconfig (amwang@...hat.com)
>>      - on block, note if the call was compat (so the # means something)
>>  v5: - uses syscall_get_arguments
>>        (indan@....nu,oleg@...hat.com, mcgrathr@...omium.org)
>>      - uses union-based arg storage with hi/lo struct to
>>        handle endianness.  Compromises between the two alternate
>>        proposals to minimize extra arg shuffling and account for
>>        endianness assuming userspace uses offsetof().
>>        (mcgrathr@...omium.org, indan@....nu)
>>      - update Kconfig description
>>      - add include/seccomp_filter.h and add its installation
>>      - (naive) on-demand syscall argument loading
>>      - drop seccomp_t (eparis@...hat.com)
>>  v4: - adjusted prctl to make room for PR_[SG]ET_NO_NEW_PRIVS
>>      - now uses current->no_new_privs
>>          (luto@....edu,torvalds@...ux-foundation.com)
>>      - assign names to seccomp modes (rdunlap@...otime.net)
>>      - fix style issues (rdunlap@...otime.net)
>>      - reworded Kconfig entry (rdunlap@...otime.net)
>>  v3: - macros to inline (oleg@...hat.com)
>>      - init_task behavior fixed (oleg@...hat.com)
>>      - drop creator entry and extra NULL check (oleg@...hat.com)
>>      - alloc returns -EINVAL on bad sizing (serge.hallyn@...onical.com)
>>      - adds tentative use of "always_unprivileged" as per
>>        torvalds@...ux-foundation.org and luto@....edu
>>  v2: - (patch 2 only)
>>
>> Signed-off-by: Will Drewry <wad@...omium.org>
>
> Hi Will,
>
> as far as I can tell based on changelog I suspect you could have
> kept my Acked-by (from v3?).  However, I'll wait until your next
> submission (as I see there were a few change requests), and do a
> final complete new review of that.

Thanks, Serge!  I just failed at the proper protocol and didn't mean
to not include your Acked-by.   However, I am changing a fair amount
of the internals this time around, so I'll be happy to have another
full review.

> Thanks for continuing to push on this.

Definitely! I've been traveling this week, so it's been a bit slow
going, but I hope to have the next rev up early next week if not
sooner.

Cheers!
will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ