From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752638AbcJCW5C (ORCPT ); Mon, 3 Oct 2016 18:57:02 -0400 Received: from mail-wm0-f46.google.com ([74.125.82.46]:38700 "EHLO mail-wm0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751725AbcJCW46 (ORCPT ); Mon, 3 Oct 2016 18:56:58 -0400 MIME-Version: 1.0 In-Reply-To: <57E16D07.4050301@digikod.net> References: <1472121165-29071-1-git-send-email-mic@digikod.net> <20160915091902.GA13132@amd> <57E16D07.4050301@digikod.net> From: Kees Cook Date: Mon, 3 Oct 2016 15:56:56 -0700 X-Google-Sender-Auth: a8NlPoG0M1OooD44Fa48Xz_O5uY Message-ID: Subject: Re: [RFC v2 00/10] Landlock LSM: Unprivileged sandboxing To: =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= Cc: Pavel Machek , LKML , Alexei Starovoitov , Andy Lutomirski , Arnd Bergmann , Casey Schaufler , Daniel Borkmann , Daniel Mack , David Drysdale , "David S . Miller" , Elena Reshetova , James Morris , Paul Moore , Sargun Dhillon , "Serge E . Hallyn" , Will Drewry , "kernel-hardening@lists.openwall.com" , Linux API , linux-security-module , Network Development Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id u93Mv8Ii004452 On Tue, Sep 20, 2016 at 10:08 AM, Mickaël Salaün wrote: > > On 15/09/2016 11:19, Pavel Machek wrote: >> Hi! >> >>> This series is a proof of concept to fill some missing part of seccomp as the >>> ability to check syscall argument pointers or creating more dynamic security >>> policies. The goal of this new stackable Linux Security Module (LSM) called >>> Landlock is to allow any process, including unprivileged ones, to create >>> powerful security sandboxes comparable to the Seatbelt/XNU Sandbox or the >>> OpenBSD Pledge. This kind of sandbox help to mitigate the security impact of >>> bugs or unexpected/malicious behaviors in userland applications. >>> >>> The first RFC [1] was focused on extending seccomp while staying at the syscall >>> level. This brought a working PoC but with some (mitigated) ToCToU race >>> conditions due to the seccomp ptrace hole (now fixed) and the non-atomic >>> syscall argument evaluation (hence the LSM hooks). >> >> Long and nice description follows. Should it go to Documentation/ >> somewhere? >> >> Because some documentation would be useful... >> Pavel > > Right, but I was looking for feedback before investing in documentation. :) Heh, understood. There are a number of grammar issues that slow me down when reading this, so when it does move into Documentation/, I'll have some English nit-picks. :) While reading I found myself wanting an explicit list of "guiding principles" for anyone implementing new hooks. It is touched on in several places (don't expose things, don't allow for privilege changes, etc). Having that spelled out somewhere would be nice. -Kees -- Kees Cook Nexus Security