linux-kernel - Re: [PATCH v7 1/6] seccomp: add a return code to trap to userspace

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180929002855.bcx5u2kabtqjtcnt@mikami>
Date:   Sat, 29 Sep 2018 10:28:55 +1000
From:   Aleksa Sarai <asarai@...e.de>
To:     Tycho Andersen <tycho@...ho.ws>
Cc:     Kees Cook <keescook@...omium.org>, Jann Horn <jannh@...gle.com>,
        linux-api@...r.kernel.org, containers@...ts.linux-foundation.org,
        Akihiro Suda <suda.akihiro@....ntt.co.jp>,
        Oleg Nesterov <oleg@...hat.com>, linux-kernel@...r.kernel.org,
        "Eric W . Biederman" <ebiederm@...ssion.com>,
        linux-fsdevel@...r.kernel.org,
        Christian Brauner <christian.brauner@...ntu.com>,
        Andy Lutomirski <luto@...capital.net>
Subject: Re: [PATCH v7 1/6] seccomp: add a return code to trap to userspace

On 2018-09-27, Tycho Andersen <tycho@...ho.ws> wrote:
> This patch introduces a means for syscalls matched in seccomp to notify
> some other task that a particular filter has been triggered.
> 
> The motivation for this is primarily for use with containers. For example,
> if a container does an init_module(), we obviously don't want to load this
> untrusted code, which may be compiled for the wrong version of the kernel
> anyway. Instead, we could parse the module image, figure out which module
> the container is trying to load and load it on the host.
> 
> As another example, containers cannot mknod(), since this checks
> capable(CAP_SYS_ADMIN). However, harmless devices like /dev/null or
> /dev/zero should be ok for containers to mknod, but we'd like to avoid hard
> coding some whitelist in the kernel. Another example is mount(), which has
> many security restrictions for good reason, but configuration or runtime
> knowledge could potentially be used to relax these restrictions.

Minor thing, but this is no longer _entirely_ true (now it checks
ns_capable(sb->s_user_ns)). I think the kernel module auto-loading is a
much more interesting example, but since this is just a commit message
feel free to ignore my pedantry. :P

> Signed-off-by: Tycho Andersen <tycho@...ho.ws>
> CC: Kees Cook <keescook@...omium.org>
> CC: Andy Lutomirski <luto@...capital.net>
> CC: Oleg Nesterov <oleg@...hat.com>
> CC: Eric W. Biederman <ebiederm@...ssion.com>
> CC: "Serge E. Hallyn" <serge@...lyn.com>
> CC: Christian Brauner <christian.brauner@...ntu.com>
> CC: Tyler Hicks <tyhicks@...onical.com>
> CC: Akihiro Suda <suda.akihiro@....ntt.co.jp>

Would you mind adding me to the Cc: list for the next round of patches?
It's looking pretty neat!

Thanks!

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)