From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1764273AbcINOjC (ORCPT ); Wed, 14 Sep 2016 10:39:02 -0400 Received: from smtp-out6.electric.net ([192.162.217.181]:53442 "EHLO smtp-out6.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1762000AbcINOi7 (ORCPT ); Wed, 14 Sep 2016 10:38:59 -0400 From: David Laight To: =?utf-8?B?J01pY2thw6tsIFNhbGHDvG4n?= , "linux-kernel@vger.kernel.org" CC: Alexei Starovoitov , Andy Lutomirski , Arnd Bergmann , Casey Schaufler , Daniel Borkmann , Daniel Mack , David Drysdale , "David S . Miller" , Elena Reshetova , "Eric W . Biederman" , James Morris , Kees Cook , Paul Moore , Sargun Dhillon , "Serge E . Hallyn" , Tejun Heo , Will Drewry , "kernel-hardening@lists.openwall.com" , "linux-api@vger.kernel.org" , "linux-security-module@vger.kernel.org" , "netdev@vger.kernel.org" , "cgroups@vger.kernel.org" Subject: RE: [RFC v3 00/22] Landlock LSM: Unprivileged sandboxing Thread-Topic: [RFC v3 00/22] Landlock LSM: Unprivileged sandboxing Thread-Index: AQHSDlqSomF+XvVtc06z71TSQ4V7S6B5DAag Date: Wed, 14 Sep 2016 14:36:40 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6DB00FC881@AcuExch.aculab.com> References: <20160914072415.26021-1-mic@digikod.net> In-Reply-To: <20160914072415.26021-1-mic@digikod.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.99.200] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-Outbound-IP: 213.249.233.130 X-Env-From: David.Laight@ACULAB.COM X-Proto: esmtps X-Revdns: X-HELO: AcuExch.aculab.com X-TLS: TLSv1:AES128-SHA:128 X-Authenticated_ID: X-PolicySMART: 3396946, 3397078 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 base64 to 8bit by mail.home.local id u8EEd7jR031338 From: Mickaël Salaün > Sent: 14 September 2016 08:24 ... > ## Why does seccomp-filter is not enough? > > A seccomp filter can access to raw syscall arguments which means that it is not > possible to filter according to pointed data as a file path. As demonstrated > the first version of this patch series, filtering at the syscall level is > complicated (e.g. need to take care of race conditions). This is mainly because > the access control checkpoints of the kernel are not at this high-level but > more underneath, at LSM hooks level. The LSM hooks are designed to handle this > kind of checks. This series use this approach to leverage the ability of > unprivileged users to limit themselves. You cannot validate file path parameters during syscall entry. It can only be done after the user buffer has been read into kernel memory. (ie you must only access the buffer once.) This has nothing to do with where the kernel does any access checks, and everything to do with the fact that another thread/process can modify the buffer after you have validated it. David