Snappy capability types and attributes

[Zygmunt Krynicki]

On Tue, Nov 17, 2015 at 5:32 PM, John Lenton <john.lenton at canonical.com> wrote:
> On 17 November 2015 at 15:11, Zygmunt Krynicki
> <zygmunt.krynicki at canonical.com> wrote:
>> 2. The second reason is that REST API is currently not something you
>> can directly access. For most intents and purposes it's not "public"
>
> 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.

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.

>
> $ sudo snappy install http.chipaca
> [progress bars happen]
> $ sudo http.GET snapd:///1.0
> HTTP/1.1 200 OK
> Content-Length: 136
> Content-Type: application/json
> Date: Tue, 17 Nov 2015 16:32:33 GMT
>
> {
>     "result": {
>         "api_compat": "0",
>         "default_channel": "edge",
>         "flavor": "core",
>         "release": "rolling"
>     },
>     "status": "OK",
>     "status_code": 200,
>     "type": "sync"
> }