Re: [RFC PATCHv2 00/11] Adding FreeBSD's Capsicum security framework

On Mon, Jul 28, 2014 at 10:13 PM, Eric W. Biederman
[off-list ref] wrote:

David Drysdale [off-list ref] writes:

quoted

On Sat, Jul 26, 2014 at 10:04 PM, Eric W. Biederman
[off-list ref] wrote:

quoted

David Drysdale [off-list ref] writes:

quoted

quoted

quoted

1) Capsicum Capabilities
------------------------

The most significant aspect of Capsicum is associating *rights* with
(some) file descriptors, so that the kernel only allows operations on an
FD if the rights permit it.  This allows userspace applications to
sandbox themselves by tightly constraining what's allowed with both
input and outputs; for example, tcpdump might restrict itself so it can
only read from the network FD, and only write to stdout.

The kernel thus needs to police the rights checks for these file
descriptors (referred to as 'Capsicum capabilities', completely
different than POSIX.1e capabilities), and the best place to do this is
at the points where a file descriptor from userspace is converted to a
struct file * within the kernel.

  [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.]

However, this does lead to quite an invasive change to the kernel --
every invocation of fget() or similar functions (fdget(),
sockfd_lookup(), user_path_at(),...) needs to be annotated with the
rights associated with the specific operations that will be performed on
the struct file.  There are ~100 such invocations that need
annotation.

And it is silly.  Roughly you just need a locking version of
fcntl(F_SETFL).

That is make the restriction in the struct file not in the fd to file
lookup.

The file status flags are far too coarse -- for example, O_RDONLY
doesn't prevent fchmod(2).

Also, because they're associated with the struct file there is no way
to pass a file descriptor with only a subset of rights across a UNIX
socket (how do I send a read-only FD corresponding to my
O_RDWR file?).

You can't.  Unix domain sockets pass struct file references.
That is passing a file descriptor with a unix domain sockets is the
equivlanet of dup().

That's my point -- if the rights are associated with the struct file
there is no way of subsetting them.  By associating rights with
the file descriptor, you can pass around different views of the
same underlying object with different rights.

You absolutely must make your struct file read-only before passing it,
otherwise the the receiver will have a read-write instance.

Even if the struct file is read-only, the recipient will still be
able to do lots of things (e.g. fchmod as mentioned previously)

This notion that a shared structure should have different semantics
depending on who is looking at it, sounds like a maintenance nightmare
to me.

I don't think it's that bad -- it's not completely different semantics,
just a strict subset of allowed operations.  Also, having a distinct
ENOTCAPABLE errno value makes it easy to spot mismatches
of required & provided rights.

quoted

quoted

Files in unix have been capabilities for more than 20 years.  That is
what file descriptor passing in unix domain sockets are all about.  We
don't need an additional ``capability rights'' layer on top of file
descriptors.

True, the ability to pass FDs across UNIX sockets is one of the
key things that makes them analogous to object-capabilities and
suitable as the substratum for Capsicum.  But the coarseness of the
existing rights, and the lack of coherent policing of those rights,
means that an (opt-in) extension like Capsicum is useful.

Finer grained restrictions are perfectly sensible.

I don't see how it make sense to place those restrictions in
struct fdtable instead of in struct file.

I see two sensible implementations:
- Add a seccomp bpf filter to struct file.
- Add permission bits to struct file.

The bpf filter would allow for a simple code extension that would
allow any arbitrary policy to be applied.

Paolo Bonzini suggested this on the previous iteration, but
I think the associated complications are too overwhelming.
Have a look at: https://lkml.org/lkml/2014/7/7/165

Adding permisison bits to struct file for gating access to
file_operations and inode_operations would result in the fastest
possible implementation and something very easy to audit and
understand.  But there like ioctl or read/write on IB control files
where finer grained permissions might be desirable.

For a lot of operations we alread have bits like FMODE_READ and
FMODE_CAN_READ on struct file for reasons such as performance
so that only a single cache line needs to be touched.

It might be that it would be worth having both.  Something cheap and
genrally accessible and something fast.

quoted

quoted

Going farther one huge thing your work and the capsicum work in general
is missing is an implementation of revoke.  With a little care a good
implementation of bits reporting and controlling which methods are
available on which file descriptors should be a good start on
a revoke implementation for linux as well.

Yeah, revocation is interesting.  There was been some discussion of
it for Capsicum a while ago:
https://lists.cam.ac.uk/pipermail/cl-capsicum-discuss/2011-January/msg00002.html
but I don't think a firm conclusion was reached.  As I understand it,
there's also a theoretical argument that revocation can be constructed
on top of the capability system, by handing out capabilities to proxy
objects that can then change their behaviour so they no longer pass
operations through.

I believe the capsicum approach is so far from allowing general proxy
objects that, that is not a compelling case.

Yeah, it is probably more of a theoretical argument than a practical
one.  But then, the requirement for revocation might fall into the same
bucket -- more desirable in theory than in practice, particularly for the
sort of application self-sandboxing and compartmentalization that
Capsicum is particularly good for.

quoted

quoted

quoted

3) Allowing Capability Mode
---------------------------

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.  More precisely, capability mode prevents access
to syscalls that access global namespaces, such as the filesystem or the
IP:port space.

The existing seccomp-bpf functionality of the kernel is a good mechanism
for implementing capability mode, but there are a few additional details
that also need to be addressed.

 a) The capability mode filter program needs to apply process-wide, not
    just to the current thread.

 b) In capability mode, new files can still be opened with openat(2) but
    only if they are beneath an existing directory file descriptor.

Which raises the question is that worth it?

From a practical point of view, still allowing (directory-relative) filesystem
access means it's much easier for an application to adapt to Capsicum.

A simple example is something like unzip/tar -xf, where locking it down
is conceptually as simple as:
 - apply a CAP_READ restriction to the FD for the input file
 - apply a CAP_WRITE+CAP_LOOKUP restriction to the DFD for the
   output directory
 - enter capability mode.
Then the worst a malicious input file can do is to write files under the
output directory -- which it could do anyway.

Similarly, migrating an application that writes temporary files out to
some tempdir is much more straightforward if openat(dfd,...) is still
allowed.

quoted

quoted

quoted

 c) In capability mode it should still be possible for a process to send
    signals to itself with kill(2)/tgkill(2).

quoted

seL4 may have a much simpler (and more formally-correct) model, but
the aim of Capsicum is to get some of the benefits of that well-analysed
model without the need for a (massive) migration effort -- and in a way
that allows co-existence of migrated and unmigrated code.

Alright. About the same target as seccomp then.  Aiming at something
that is simple to adopt sounds like a reasonable goal.

quoted

quoted

quoted

5) New openat(2) O_BENEATH Flag
-------------------------------

For Capsicum capabilities that are directory file descriptors, the
Capsicum framework only allows openat(cap_dfd, path, ...) operations to
work for files that are beneath the specified directory (and even that
only when the directory FD has the CAP_LOOKUP right), rejecting paths
that start with "/" or include "..".  The same restriction applies
process-wide for a process in capability mode.

As this seemed like functionality that might be more generally useful,
I've implemented it independently as a new O_BENEATH flag for openat(2).
The Capsicum code then always triggers the use of that flag when the dfd
is a Capsicum capability, or when the prctl(2) command described above
is in play.

  [FreeBSD has the openat(2) relative-only behaviour for capability DFDs
  and processes in capability mode, but does not include the O_BENEATH
  flag.]

If you are going to allow open I would think the simple solution here is
to just create a mount namespace that only has available the files you
would like to export to the process, and force all of the file
descriptors into that mount namespace.

quoted

I think that's a lot harder for application writers to do -- they would need
to have CAP_SYS_ADMIN to set up the namespace & mounts before
dropping privileges.

They only need CAP_SYS_ADMIN in their local user namespace, which anyone
is allowed to create.

quoted

And the net result would again be much less
fine-grained (e.g. for the unzip example above, the specific capability
rights prevent reading of any files that already exist in the output
directory).

Nope.  What you can implement today if you want fine grained limitations
like this is to create a mount namespace with exactly the subdirectory
tree you want to allow access to and to return a file descriptor that
points into that mount namespace.  (When complete the only user of that
mount namespace would be your file descriptor).

How does that solve the particular example I mentioned?  The DFD
within the mount namespace will still allow any operation on any file
that's already in the subdirectory -- or am I misunderstanding
something?

In fact that solution is sufficiently performant and simple that even
if you came up with a better user space interface for it that is how we
would want to implement it.

And frankly that already exists today so I think a fairly large burden
of proof needs to be met to suggest that we need to add additional
functionality to the kernel.

Furthermore I think it makes sense for application authors to use
as otherwise they will have to wait a year or so for the debates to be
finished and your new functionality to be merged.

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.

Eric

Capability mode would impose a process wide restriction to relative
paths -- see sections 3) and 5) of the original mail.