Unconfined aggregating scope can't call confined child scope to get results

Bug #1347177 reported by Chris Wayne
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
The Savilerow project
Fix Released
Critical
Unassigned
unity-scopes-api
Invalid
Undecided
Unassigned
apparmor-easyprof-ubuntu (Ubuntu)
Fix Released
Critical
Jamie Strandboge

Bug Description

An unconfined scope is getting apparmor denials while getting results from a confined child scope. The denials:

Jul 22 17:06:40 ubuntu-phablet kernel: [30750.996517] type=1400 audit(1406063200.136:2410): apparmor="DENIED" operation="connect" profile="com.canonical.scopes.etsy_etsy_1.0.9" name="/run/user/32011/zmq/unity-scope-shopping-r" pid=19097 comm="com.canonical.s" requested_mask="rw" denied_mask="rw" fsuid=32011 ouid=32011

The child scope has the template: ubuntu-scope-network and can run fine on its own

Chris Wayne (cwayne)
Changed in savilerow:
status: New → Confirmed
importance: Undecided → Critical
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

We specifically disallow access to '/run/user/[0-9]*/zmq/*-r' except for '/run/user/[0-9]*/zmq/@{APP_PKGNAME}_@{APP_APPNAME}-r' since otherwise confined scopes could mess with each other. It was my understanding that aggregating scopes could call confined scopes without problems (in fact, I thought I remembered that is what the '/run/user/[0-9]*/zmq/c*-r' endpoints were for).

I'm not sure if the unity-scopes-api has a bug or this is a design issue, but we can't allow '/run/user/[0-9]*/zmq/*-r' in the policy.

tags: added: application-confinement
Revision history for this message
Michi Henning (michihenning) wrote :

The zmq/*-r endpoints are for a client to receive replies in response to queries. Basically, when a client creates a query, it passes an invocation handle to the query that points at the zmq/*-r endpoint. The scope sends push messages to that endpoint to deliver the results.

It's OK for anything to connect to the reply endpoint and write to it. If the message arriving at that endpoint doesn't make sense (is malformed in some way, so it doesn't decode correctly, or similar), the message is discarded.

Each message has its internal structure. One of the things it contains is an object identifier (a UUID) that determines which query the reply is for (because a client may potentially have several queries in progress concurrently). When the client creates the query, it generates a new UUID for each query; that UUID is embedded in the invocation handle that is passed to the scope, and the UUID goes on the wire when the client pushes the results.

If a push arrives at the client's zmq/*-r endpoint with a UUID that doesn't correspond to the UUID of a currently outstanding query, the message is discarded.

So, the absolute worst that could happen is that a malicious process could try to push results to the reply endpoint of a client while the client has a query in progress, in an attempt to inject fake query results into the client. For that to work, the attacker would have to correctly guess the UUID for the query, and would have to do so while real scope is still busy executing the query. The UUIDs have 64 bits of entropy that comes from a Mersenne twister. I thought that this would make it sufficiently secure?

Query *creation* needs to be secured, and query creation in a scope happens via the zmq/*-q endpoint. Confined scopes must not be able to connect other scopes' query endpoint, but unconfined scopes should be allowed to, whether the target is confined or not.

Revision history for this message
Michi Henning (michihenning) wrote :

> and the UUID goes on the wire when the client pushes the results.

Sorry, that should have read "and the UUID goes on the wire when the *scope* pushes the results."

Revision history for this message
Michi Henning (michihenning) wrote :

> The UUIDs have 64 bits of entropy that comes from a Mersenne twister.

Correction: it's 32 bits at the moment, but we could make it 64 bits very easily.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Ok, I'll preserve the scope-specific names for the -c and -q files in zmq/priv, but add a glob for zmq/*-r.

Changed in unity-scopes-api:
status: New → Invalid
Changed in apparmor-easyprof-ubuntu (Ubuntu):
status: New → In Progress
importance: Undecided → Critical
assignee: nobody → Jamie Strandboge (jdstrand)
Revision history for this message
Michi Henning (michihenning) wrote :

Cool, thanks for that Jamie!

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Uploaded 1.2.12 to utopic-proposed just now.

Changed in apparmor-easyprof-ubuntu (Ubuntu):
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apparmor-easyprof-ubuntu - 1.2.12

---------------
apparmor-easyprof-ubuntu (1.2.12) utopic; urgency=medium

  * ubuntu/1.2/ubuntu-scope-network: allow rw on zmq/*-r reply endpoints. The
    scopes-api has protections for malformed or non-UUID-matching replies, so
    use a glob here to allow aggregating scopes to work. (LP: #1347177)
 -- Jamie Strandboge <email address hidden> Wed, 23 Jul 2014 10:15:17 -0500

Changed in apparmor-easyprof-ubuntu (Ubuntu):
status: Fix Committed → Fix Released
Changed in savilerow:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.