Re: RFC: fsyscall

From	"Serge E. Hallyn" <serge@hallyn.com>
Newsgroups	linux.kernel
Subject	Re: RFC: fsyscall
Date	2015-09-10 15:40 +0200
Message-ID	<q7af2-2PS-33@gated-at.bofh.it> (permalink)
References	(2 earlier) <q6Alb-1Zd-1@gated-at.bofh.it> <q6Alb-1Zd-15@gated-at.bofh.it> <q6BAB-3Go-5@gated-at.bofh.it> <q6Rm2-1gb-9@gated-at.bofh.it> <q6Txv-4jy-15@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Thread

RFC: fsyscall ebiederm@xmission.com (Eric W. Biederman) - 2015-09-09 00:50 +0200
  Re: RFC: fsyscall Andy Lutomirski <luto@amacapital.net> - 2015-09-09 01:00 +0200
    Re: RFC: fsyscall ebiederm@xmission.com (Eric W. Biederman) - 2015-09-09 01:20 +0200
      Re: RFC: fsyscall Andy Lutomirski <luto@amacapital.net> - 2015-09-09 01:20 +0200
        Re: RFC: fsyscall ebiederm@xmission.com (Eric W. Biederman) - 2015-09-09 02:40 +0200
          Re: RFC: fsyscall David Drysdale <drysdale@google.com> - 2015-09-09 19:30 +0200
            Re: RFC: fsyscall ebiederm@xmission.com (Eric W. Biederman) - 2015-09-09 21:50 +0200
              Re: RFC: fsyscall "Serge E. Hallyn" <serge@hallyn.com> - 2015-09-10 15:40 +0200
            Re: RFC: fsyscall "Serge E. Hallyn" <serge@hallyn.com> - 2015-09-10 15:30 +0200
          Re: RFC: fsyscall "Serge E. Hallyn" <serge@hallyn.com> - 2015-09-10 15:50 +0200
            Re: RFC: fsyscall David Drysdale <drysdale@google.com> - 2015-09-10 16:00 +0200
              Re: RFC: fsyscall "Serge E. Hallyn" <serge@hallyn.com> - 2015-09-10 16:10 +0200
                Re: RFC: fsyscall "Serge E. Hallyn" <serge@hallyn.com> - 2015-09-10 16:10 +0200
                Re: RFC: fsyscall "Serge E. Hallyn" <serge@hallyn.com> - 2015-09-10 16:10 +0200

csiph-web