All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>,
	David Drysdale <drysdale@google.com>
Cc: LSM List <linux-security-module@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Meredydd Luff <meredydd@senatehouse.org>,
	Kees Cook <keescook@chromium.org>,
	James Morris <james.l.morris@oracle.com>,
	Andy Lutomirski <luto@amacapital.net>,
	Paul Moore <paul@paul-moore.com>,
	Christoph Hellwig <hch@infradead.org>,
	Linux API <linux-api@vger.kernel.org>
Subject: Re: [RFC PATCHv2 00/11] Adding FreeBSD's Capsicum security framework
Date: Tue, 29 Jul 2014 10:43:34 +0200	[thread overview]
Message-ID: <53D75EB6.1090301@redhat.com> (raw)
In-Reply-To: <87ha21qja0.fsf@x220.int.ebiederm.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

WARNING: multiple messages have this Message-ID (diff)
From: Paolo Bonzini <pbonzini-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: "Eric W. Biederman"
	<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>,
	David Drysdale <drysdale-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Cc: LSM List
	<linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Greg Kroah-Hartman
	<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
	Alexander Viro
	<viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
	Meredydd Luff <meredydd-zPN50pYk8eUaUu29zAJCuw@public.gmane.org>,
	Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
	James Morris
	<james.l.morris-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>,
	Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>,
	Paul Moore <paul-r2n+y4ga6xFZroRs9YW3xA@public.gmane.org>,
	Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
	Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [RFC PATCHv2 00/11] Adding FreeBSD's Capsicum security framework
Date: Tue, 29 Jul 2014 10:43:34 +0200	[thread overview]
Message-ID: <53D75EB6.1090301@redhat.com> (raw)
In-Reply-To: <87ha21qja0.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.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

  reply	other threads:[~2014-07-29  8:44 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-25 13:46 [RFC PATCHv2 00/11] Adding FreeBSD's Capsicum security framework David Drysdale
2014-07-25 13:46 ` [PATCH 01/11] fs: add O_BENEATH flag to openat(2) David Drysdale
2014-07-25 13:46 ` [PATCH 02/11] selftests: Add test of O_BENEATH & openat(2) David Drysdale
2014-07-25 13:46 ` [PATCH 03/11] capsicum: rights values and structure definitions David Drysdale
2014-07-25 13:47 ` [PATCH 04/11] capsicum: implement fgetr() and friends David Drysdale
2014-07-25 13:47   ` David Drysdale
2014-07-25 13:47 ` [PATCH 05/11] capsicum: convert callers to use fgetr() etc David Drysdale
2014-07-25 13:47   ` David Drysdale
2014-07-25 13:47 ` [PATCH 06/11] capsicum: implement sockfd_lookupr() David Drysdale
2014-07-25 13:47 ` [PATCH 07/11] capsicum: convert callers to use sockfd_lookupr() etc David Drysdale
2014-07-25 13:47 ` [PATCH 08/11] capsicum: invoke Capsicum on FD/file conversion David Drysdale
2014-07-25 13:47 ` [PATCH 09/11] capsicum: add syscalls to limit FD rights David Drysdale
2014-07-25 13:47   ` David Drysdale
2014-07-25 13:47 ` [PATCH 10/11] capsicum: prctl(2) to force use of O_BENEATH David Drysdale
2014-07-25 13:47   ` David Drysdale
2014-07-25 14:01   ` Paolo Bonzini
2014-07-25 16:00     ` Andy Lutomirski
2014-07-27 12:08       ` David Drysdale
2014-07-25 13:47 ` [PATCH 11/11] seccomp: Add tgid and tid into seccomp_data David Drysdale
2014-07-25 15:59   ` Andy Lutomirski
2014-07-25 17:10     ` Kees Cook
2014-07-25 17:18       ` Andy Lutomirski
2014-07-25 17:38         ` Kees Cook
2014-07-25 18:24           ` Julien Tinnes
2014-07-25 18:24             ` Julien Tinnes
     [not found]           ` <CAKyRK=j-f92xHTL3+TNr9WOv_y47dkZR=WZkpY_a5YW3Q8HfaQ@mail.gmail.com>
2014-07-25 18:32             ` Andy Lutomirski
2014-07-27 12:10               ` David Drysdale
2014-07-27 12:10                 ` David Drysdale
2014-07-27 12:09         ` David Drysdale
2014-07-28 21:18         ` Eric W. Biederman
2014-07-28 21:18           ` Eric W. Biederman
2014-07-30  4:05           ` Andy Lutomirski
2014-07-30  4:05             ` Andy Lutomirski
2014-07-30  4:08             ` Eric W. Biederman
2014-07-30  4:08               ` Eric W. Biederman
2014-07-30  4:35               ` Andy Lutomirski
     [not found]                 ` <8761ifie81.fsf@x220.int.ebiederm.org>
2014-07-30 14:52                   ` Andy Lutomirski
2014-07-30 14:52                     ` Andy Lutomirski
2014-07-25 13:47 ` [PATCH 1/6] open.2: describe O_BENEATH flag David Drysdale
2014-07-25 13:47 ` [PATCH 2/6] capsicum.7: describe Capsicum capability framework David Drysdale
2014-07-25 13:47 ` [PATCH 3/6] rights.7: Describe Capsicum primary rights David Drysdale
2014-07-25 13:47 ` [PATCH 4/6] cap_rights_limit.2: limit FD rights for Capsicum David Drysdale
2014-07-25 13:47 ` [PATCH 5/6] cap_rights_get.2: retrieve Capsicum fd rights David Drysdale
2014-07-25 13:47 ` [PATCH 6/6] prctl.2: describe PR_SET_OPENAT_BENEATH/PR_GET_OPENAT_BENEATH David Drysdale
2014-07-25 13:47   ` David Drysdale
2014-07-26 21:04 ` [RFC PATCHv2 00/11] Adding FreeBSD's Capsicum security framework Eric W. Biederman
2014-07-26 21:04   ` Eric W. Biederman
2014-07-28 12:30   ` Paolo Bonzini
2014-07-28 12:30     ` Paolo Bonzini
2014-07-28 16:04   ` David Drysdale
2014-07-28 21:13     ` Eric W. Biederman
2014-07-28 21:13       ` Eric W. Biederman
2014-07-29  8:43       ` Paolo Bonzini [this message]
2014-07-29  8:43         ` Paolo Bonzini
2014-07-29 10:58       ` David Drysdale
2014-07-30  6:22         ` Eric W. Biederman
2014-07-30  6:22           ` Eric W. Biederman
2014-07-30 14:51           ` Andy Lutomirski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53D75EB6.1090301@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=drysdale@google.com \
    --cc=ebiederm@xmission.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@infradead.org \
    --cc=james.l.morris@oracle.com \
    --cc=keescook@chromium.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=meredydd@senatehouse.org \
    --cc=paul@paul-moore.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.