Re: Sandbox thoughts

On tis, 2015-02-17 at 13:23 -0800, Andy Lutomirski wrote:
[I'm not a gnome-os subscriber.  Let's see whether this bounces as a result.]

Hi all-

I just read Alexander's blog post about Neverball in a sandbox.  Neat stuff!

Here are some thoughts, in no particular order:

 - seccomp.  Seccomp will help a lot, especially in avoiding attacks
against more obscure kernel interfaces.  There's a decent
blacklist-based sandbox I worked on here:

Ideally it would be a whitelist, not a blacklist, but this set of
filter rules blocked a whole bunch of kernel vulnerabilities that
showed up after I wrote the rules.

Cool. I'll be sure to steal liberally from this.

Some comments:

  // AIO is scary.
Really? This seems like it is something that could be useful to apps, is
it not?

Also, vmsplice seems like it could be useful too.

For reference, here is what systemd-nspawn uses:

It has some things you don't, such as: module calls, iopl, swap*, kexec,

As on Linux 3.18 (IIRC), seccomp has reasonably low overhead.  (It was
terrible before that.)  If you try it and have issues, performance or
otherwise, please let me know.  On new kernels, the overhead should be
well under 100 cycles per syscall plus the filter execution time.

 - setuid / privileged helper.  Why do you need a privileged helper?
You should be able to do all of this using user namespaces.  The
Sandstorm code linked above does exactly this.

I have not yet looked into using user namespaces because historically
they have been disabled for non-root users in distros like fedora an
ubuntu. However, it seems like this is slowly lifted, so we should be
able to use this when possible to allow the privilege increase.

Can we really do everything though? i.e. can the setup code run mknod in
the user namespace?

 - netns.  Having an IPv6 loopback is probably good, too.  You might
get this by default with no particular action required on your part,

It just needs some code to bring up the interface (like the ipv4 one), i
was just lazy and did not add it. Should be a small matter of code.

 - kdbus.  Why do you need kdbus?  Wouldn't a userspace proxy work
fine?  Even with kdbus, I imagine you're using the restricted endpoint
features, and I wasn't quite convinced that the design would allow
very flexible and clearly secure sandboxing.  If I were designing a
sandbox that used kdbus, I'd mount a fresh "domain" (aka kdbusfs) in
the sandbox and I'd still want to proxy everything explicitly.  That
way the sandboxed code could still use kdbus however it wanted.  What
has your experience using it been like?

Its hard to do a proper userspace proxy of dbus. For instance, it is
inherently racy to limit access to a well known name as many clients use
the unique name to talk to a service, but the
unique-name<->well-known-name mapping can change asynchronously from the
proxy. Also, not having the peer side of the dbus client be the *real*
client process breaks some dbus functionality (for instance, the proxy
would run outside the app sandbox, so you wouldn't get the right
pid/cgroup data to know that a dbus peer was in a sandbox).

The expected setup is that the app can only talk to the session/user
bus. It can only own its own name (the app id like "org.gnome.gedit"),
and it can only talk to a selected set of dbus names that have been
deemed safe. These would include a set of "portal" APIs that contains
the functionality needed to interact with the desktop. For instance
there would be some kind of api to request the user to open a file, with
the file selector happening on the non-sandbox side, and a stream of the
selected data being returned to the app.

I have not actually started playing with kdbus in detail though, so this
part is very much uncharted waters.

 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's a suave moralistic assassin on the wrong side of the law. She's an 
elegant belly-dancing mechanic with an evil twin sister. They fight 

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]