On Feb 18, 2015 1:11 AM, "Alexander Larsson" <alexl redhat com> wrote:
>
> 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:
> >
> > https://github.com/sandstorm-io/sandstorm/blob/master/src/sandstorm/supervisor.c%2B%2B
> >
> > 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?
It's useful, but it's a poorly designed interface, so it's rarely used and hard to debug. That being said, I bet it's fine for the gnome sandbox.
>
> Also, vmsplice seems like it could be useful too.
Given that SPLICE_F_MOVE is disabled, I don't think it's actually useful. IIRC SPLICE_F_GIFT is inherently insecure and impossible to use usefully, so I don't think it does anything. IOW, vmsplice scares the crap out of me and nothing should use it.
memfd is IMO a far, far better interface than vmsplice.
>
> For reference, here is what systemd-nspawn uses:
> http://cgit.freedesktop.org/systemd/systemd/tree/src/nspawn/nspawn.c#n2482
>
> It has some things you don't, such as: module calls, iopl, swap*, kexec,
> open_by_handle_at.
I didn't worry about those, since you need global privilege to use them in the first place.
>
> > 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?
You can't use mknod, but you can bind-mount device nodes.
>
> > - netns. Having an IPv6 loopback is probably good, too. You might
> > get this by default with no particular action required on your part,
> > though.
>
> 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.
I think this is related to something I really didn't like when reviewing kdbus: the policy mechanism seems totally backwards wrt unique-names. Grr. I don't have any great ideas except a retroactive one: a unique-name should be resolvable *back* to a single well-known-name so that it can be used for security policy and to improve comprehensibility. Oh, well.
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).
Hmm. Kdbus has an explicit spoofing mechanism for this. Does userspace dbus not have one?
Shouldn't the sandbox be responsible for sandbox policy as opposed to the daemons you allow access to being responsible for restricting what sandboxed apps can do?
>
> 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.
>
I always imagined that these portal APIs would be implemented by the sandbox itself. I could easily be missing any number of disadvantages here, but wouldn't that allow the sandbox to confine to app to a private bus/domain and to expose the portal APIs directly to that bus/domain? This would avoid the unique-name issues, and it would also avoid needing to know whether a specific caller is sandboxed, because the callers are always in the sandbox.
With the cgroup + restricted endpoint model, how would one map a cgroup to a sandbox? ISTM this would require a universally agreed upon convention about cgroup names, and that seems overcomplicated to me.
--Andy
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 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
> crime!
>