Snappy capability types and attributes

[Gustavo Niemeyer]

On Tue, Nov 17, 2015 at 2:44 PM, Zygmunt Krynicki <
zygmunt.krynicki at canonical.com> wrote:
>
> > This isn't exactly true, though; all you need is something that knows
> > how to talk http over a unix socket. e.g.,
>
> Well, that sudo is something of a security loophole.
>
> My point was that it's not _meant_ to be accessed by every snap on the
> system and we'll probably grant special capability to select
> applications to let them actually open that socket to begin with.
>

The REST API is definitely headed to be usable by any snap in the system,
and that was always the plan I was aware of. We don't do that today because
we don't have to, and in those cases simplicity wins.

My point, though (and perhaps John's, if I understand what he's saying), is
that if we _wanted_ to open it up to snaps, there are easy paths we can use
to do so. We're not doing that with capability events because it feels like
a poor experience. So it's a design issue, rather than an implementation
one.

So, why would it be a good idea to use an HTTP-based API, in the first
place? What is the experience we want people to _have_ (rather than _not_
have)?

There are also security implications. I know go is miles ahead of C in
> buffer overflows so it's harder to exploit but I don't know if we've

really done any security review of the IPC layer, where the layer
> includes parsing parts of the HTTP request and dispatching it to a
> correct Command object. If we can crash the system by pushing a big
> request across, it's still a DOS attack that you can mount. Ironically
> today you can remove a nasty snap with "snappy remove" but when snapd
> is itself talking to snappy over a socket (a future I hope we are
> going to) then snapd can be kept offline / crashing by one program
> that just sends a nasty payload to it all the time.
>

Can we please get back to designing capabilities?


gustavo @ http://niemeyer.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20151117/d2b1b084/attachment.html>