From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752882AbaG2IoP (ORCPT ); Tue, 29 Jul 2014 04:44:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:17376 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751430AbaG2IoM (ORCPT ); Tue, 29 Jul 2014 04:44:12 -0400 Message-ID: <53D75EB6.1090301@redhat.com> Date: Tue, 29 Jul 2014 10:43:34 +0200 From: Paolo Bonzini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Eric W. Biederman" , David Drysdale CC: LSM List , "linux-kernel@vger.kernel.org" , Greg Kroah-Hartman , Alexander Viro , Meredydd Luff , Kees Cook , James Morris , Andy Lutomirski , Paul Moore , Christoph Hellwig , Linux API Subject: Re: [RFC PATCHv2 00/11] Adding FreeBSD's Capsicum security framework References: <1406296033-32693-1-git-send-email-drysdale@google.com> <871tt796i0.fsf@x220.int.ebiederm.org> <87ha21qja0.fsf@x220.int.ebiederm.org> In-Reply-To: <87ha21qja0.fsf@x220.int.ebiederm.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Il 28/07/2014 23:13, Eric W. Biederman ha scritto: > This notion that a shared structure should have different semantics > depending on who is looking at it, sounds like a maintenance nightmare > to me. Isn't that already with seccomp BPF filters? You can have the parent process set a BPF filter that forbids read on that file descriptor or write on that file descriptor. Effectively, this patchset provides the functionality to "hotplug" BPF filters on a running process as more file descriptors are passed via SCM_RIGHTS. Except it doesn't use BPF filters, and instead uses a separate set of discrete capabilities. > I see two sensible implementations: > - Add a seccomp bpf filter to struct file. I proposed something like this, but it has some additional implementation complications. See the v1 thread. But it does have to be in a file descriptor rather than a struct file. It's part of the model that two processes can have different views of the file descriptor (again my toy example is that of an eventfd that an unprivileged child process can only write to). > Additionally unless there is a process wide restriction to relative > paths I can trivially escape your relative path implementation by simply > doing open(.) and getting a struct file without any of those > restrictions. Yes, there is a prctl for that. Paolo From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [RFC PATCHv2 00/11] Adding FreeBSD's Capsicum security framework Date: Tue, 29 Jul 2014 10:43:34 +0200 Message-ID: <53D75EB6.1090301@redhat.com> References: <1406296033-32693-1-git-send-email-drysdale@google.com> <871tt796i0.fsf@x220.int.ebiederm.org> <87ha21qja0.fsf@x220.int.ebiederm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <87ha21qja0.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: "Eric W. Biederman" , David Drysdale Cc: LSM List , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Greg Kroah-Hartman , Alexander Viro , Meredydd Luff , Kees Cook , James Morris , Andy Lutomirski , Paul Moore , Christoph Hellwig , Linux API List-Id: linux-api@vger.kernel.org Il 28/07/2014 23:13, Eric W. Biederman ha scritto: > This notion that a shared structure should have different semantics > depending on who is looking at it, sounds like a maintenance nightmare > to me. Isn't that already with seccomp BPF filters? You can have the parent process set a BPF filter that forbids read on that file descriptor or write on that file descriptor. Effectively, this patchset provides the functionality to "hotplug" BPF filters on a running process as more file descriptors are passed via SCM_RIGHTS. Except it doesn't use BPF filters, and instead uses a separate set of discrete capabilities. > I see two sensible implementations: > - Add a seccomp bpf filter to struct file. I proposed something like this, but it has some additional implementation complications. See the v1 thread. But it does have to be in a file descriptor rather than a struct file. It's part of the model that two processes can have different views of the file descriptor (again my toy example is that of an eventfd that an unprivileged child process can only write to). > Additionally unless there is a process wide restriction to relative > paths I can trivially escape your relative path implementation by simply > doing open(.) and getting a struct file without any of those > restrictions. Yes, there is a prctl for that. Paolo