From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753166AbbIJNfs (ORCPT ); Thu, 10 Sep 2015 09:35:48 -0400 Received: from h2.hallyn.com ([78.46.35.8]:40805 "EHLO h2.hallyn.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752233AbbIJNfp (ORCPT ); Thu, 10 Sep 2015 09:35:45 -0400 Date: Thu, 10 Sep 2015 08:35:43 -0500 From: "Serge E. Hallyn" To: "Eric W. Biederman" Cc: David Drysdale , Andy Lutomirski , "linux-kernel@vger.kernel.org" , "Serge E. Hallyn" Subject: Re: RFC: fsyscall Message-ID: <20150910133543.GB27602@mail.hallyn.com> References: <874mj4o7yd.fsf@x220.int.ebiederm.org> <8737yomrwm.fsf@x220.int.ebiederm.org> <87mvwwfngy.fsf@x220.int.ebiederm.org> <87a8svcrr9.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87a8svcrr9.fsf@x220.int.ebiederm.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 09, 2015 at 02:33:14PM -0500, Eric W. Biederman wrote: ... > If I assume that anything file descriptor based will need another > mechanism to filter what is allowed on a file descriptor, and as such > will need a different mechanism (capsicum perhaps?). That handily > reduces the problem space, and removes almost all cases where reading > data from userspace is interesting as I am talking about pure system calls. > > The list of system calls which are not file descriptor based are listed > below. Most of those don't take weird parameter structures that would > be interesting to filter. So I think my fsyscall idea is conceptually > reasonable. It is not a complete solution for passing someone a well > defined subset you are allowed to do but it is interesting. ... > creat Taking this as a specific example, I'm somewhat fond of the idea of saying that we can support openat() as fd-based (let's say capsicum-based as we know that can work), and therefore we don't need open() or creat(). If you're designing an app so that you can fork a task with a subset of your capabilities, then you're writing it now anyway, so there is no reason for supporting open and creat. Since these are specifically very subject to TOCTTOU, saying "you must use openat()" seems ok. -serge