From: Paolo Bonzini <pbonzini@redhat.com>
To: David Drysdale <drysdale@google.com>,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Meredydd Luff <meredydd@senatehouse.org>,
Kees Cook <keescook@chromium.org>,
James Morris <james.l.morris@oracle.com>,
linux-api@vger.kernel.org, qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [RFC PATCH 00/11] Adding FreeBSD's Capsicum security framework (part 1)
Date: Thu, 03 Jul 2014 11:12:33 +0200 [thread overview]
Message-ID: <53B51E81.4090700@redhat.com> (raw)
In-Reply-To: <1404124096-21445-1-git-send-email-drysdale@google.com>
Il 30/06/2014 12:28, David Drysdale ha scritto:
> Hi all,
>
> The last couple of versions of FreeBSD (9.x/10.x) have included the
> Capsicum security framework [1], which allows security-aware
> applications to sandbox themselves in a very fine-grained way. For
> example, OpenSSH now (>= 6.5) uses Capsicum in its FreeBSD version to
> restrict sshd's credentials checking process, to reduce the chances of
> credential leakage.
Hi David,
we've had similar goals in QEMU. QEMU can be used as a virtual machine
monitor from the command line, but it also has an API that lets a
management tool drive QEMU via AF_UNIX sockets. Long term, we would
like to have a restricted mode for QEMU where all file descriptors are
obtained via SCM_RIGHTS or /dev/fd, and syscalls can be locked down.
Currently we do use seccomp v2 BPF filters, but unfortunately this
didn't help very much. QEMU supports hotplugging hence the filter must
whitelist anything that _might_ be used in the future, which is
generally... too much.
Something like Capsicum would be really nice because it attaches
capabilities to file descriptors. However, I wonder however how
extensible Capsicum could be, and I am worried about the proliferation
of capabilities that its design naturally leads to.
Given Linux's previous experience with BPF filters, what do you think
about attaching specific BPF programs to file descriptors? Then
whenever a syscall is run that affects a file descriptor, the BPF
program for the file descriptor (attached to a struct file* as in
Capsicum) would run in addition to the process-wide filter.
An equivalent of PR_SET_NO_NEW_PRIVS can also be added to file
descriptors, so that a program that doesn't lock down syscalls can still
lock down the operations (including fcntls and ioctls) on specific file
descriptors.
Converting FreeBSD capabilities to BPF programs can be easily
implemented in userspace.
> [Capsicum also includes 'capability mode', which locks down the
> available syscalls so the rights restrictions can't just be bypassed
> by opening new file descriptors; I'll describe that separately later.]
This can also be implemented in userspace via seccomp and
PR_SET_NO_NEW_PRIVS.
> [Policing the rights checks anywhere else, for example at the system
> call boundary, isn't a good idea because it opens up the possibility
> of time-of-check/time-of-use (TOCTOU) attacks [2] where FDs are
> changed (as openat/close/dup2 are allowed in capability mode) between
> the 'check' at syscall entry and the 'use' at fget() invocation.]
In the case of BPF filters, I wonder if you could stash the BPF
"environment" somewhere and then use it at fget() invocation.
Alternatively, it can be reconstructed at fget() time, similar to your
introduction of fgetr().
Thanks,
Paolo
next prev parent reply other threads:[~2014-07-03 9:12 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-30 10:28 [RFC PATCH 00/11] Adding FreeBSD's Capsicum security framework (part 1) David Drysdale
2014-06-30 10:28 ` [PATCH 01/11] fs: add O_BENEATH_ONLY flag to openat(2) David Drysdale
2014-06-30 14:49 ` Andy Lutomirski
2014-06-30 15:49 ` David Drysdale
2014-06-30 15:53 ` Andy Lutomirski
2014-07-08 12:07 ` Christoph Hellwig
2014-07-08 12:48 ` Meredydd Luff
2014-07-08 12:51 ` Christoph Hellwig
2014-07-08 13:04 ` Meredydd Luff
2014-07-08 13:12 ` Christoph Hellwig
2014-06-30 20:40 ` Andi Kleen
2014-06-30 21:11 ` Andy Lutomirski
2014-07-01 9:53 ` David Drysdale
2014-07-01 18:58 ` Loganaden Velvindron
2014-07-08 12:03 ` Christoph Hellwig
2014-07-08 16:54 ` David Drysdale
2014-07-09 8:48 ` Christoph Hellwig
2014-06-30 10:28 ` [PATCH 02/11] selftests: Add test of O_BENEATH_ONLY & openat(2) David Drysdale
2014-06-30 10:28 ` [PATCH 03/11] capsicum: rights values and structure definitions David Drysdale
2014-06-30 10:28 ` [PATCH 04/11] capsicum: implement fgetr() and friends David Drysdale
2014-06-30 10:28 ` [PATCH 05/11] capsicum: convert callers to use fgetr() etc David Drysdale
2014-06-30 10:28 ` [PATCH 06/11] capsicum: implement sockfd_lookupr() David Drysdale
2014-06-30 10:28 ` [PATCH 07/11] capsicum: convert callers to use sockfd_lookupr() etc David Drysdale
2014-06-30 10:28 ` [PATCH 08/11] capsicum: add new LSM hooks on FD/file conversion David Drysdale
2014-06-30 10:28 ` [PATCH 09/11] capsicum: implementations of new LSM hooks David Drysdale
2014-06-30 16:05 ` Andy Lutomirski
2014-07-02 13:49 ` Paul Moore
2014-07-02 17:09 ` David Drysdale
2014-06-30 10:28 ` [PATCH 10/11] capsicum: invocation " David Drysdale
2014-06-30 10:28 ` [PATCH 11/11] capsicum: add syscalls to limit FD rights David Drysdale
2014-06-30 10:28 ` [PATCH 1/5] man-pages: open.2: describe O_BENEATH_ONLY flag David Drysdale
2014-06-30 22:22 ` Andy Lutomirski
2014-06-30 10:28 ` [PATCH 2/5] man-pages: capsicum.7: describe Capsicum capability framework David Drysdale
2014-06-30 10:28 ` [PATCH 3/5] man-pages: rights.7: Describe Capsicum primary rights David Drysdale
2014-06-30 10:28 ` [PATCH 4/5] man-pages: cap_rights_limit.2: limit FD rights for Capsicum David Drysdale
2014-06-30 14:53 ` Andy Lutomirski
2014-06-30 15:35 ` David Drysdale
2014-06-30 16:06 ` Andy Lutomirski
2014-06-30 16:32 ` David Drysdale
2014-06-30 10:28 ` [PATCH 5/5] man-pages: cap_rights_get: retrieve Capsicum fd rights David Drysdale
2014-06-30 22:28 ` Andy Lutomirski
2014-07-01 9:19 ` David Drysdale
2014-07-01 14:18 ` Andy Lutomirski
2014-07-03 9:12 ` Paolo Bonzini [this message]
2014-07-03 10:01 ` [RFC PATCH 00/11] Adding FreeBSD's Capsicum security framework (part 1) Loganaden Velvindron
2014-07-03 18:39 ` David Drysdale
2014-07-04 7:03 ` Paolo Bonzini
2014-07-07 10:29 ` David Drysdale
2014-07-07 12:20 ` Paolo Bonzini
2014-07-07 14:11 ` David Drysdale
2014-07-07 22:33 ` Alexei Starovoitov
2014-07-08 14:58 ` Kees Cook
2014-08-16 15:41 ` Pavel Machek
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=53B51E81.4090700@redhat.com \
--to=pbonzini@redhat.com \
--cc=drysdale@google.com \
--cc=gregkh@linuxfoundation.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=meredydd@senatehouse.org \
--cc=qemu-devel@nongnu.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).