ubuntu-phone team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxxxxx>]

On 10/03/2014 07:41 AM, Chris Wayne wrote:
> 
> 
> On Fri, Oct 3, 2014 at 4:15 AM, Alberto Mardegan <alberto.mardegan@xxxxxxxxxxxxx
> <mailto:alberto.mardegan@xxxxxxxxxxxxx>> wrote:
> 
>     On 10/03/2014 09:53 AM, James Henstridge wrote:
>     > So how does an app/scope/whatever get itself added to this ACL?
>     > Should signond be doing a trust store check when a process with an
>     > unknown AppArmor label tries to access an account's secrets so the
>     > user can decide?
> 
>     Not exactly: the way that it's designed to work is that if the ACL check
>     fails, the access is just denied, without any user prompting. User
>     prompting happens before an application starts using an account, and
>     there's an API for that, which -- if the user granted access -- will
>     cause the app to be added to the ACL.
>     More on this below.
> 
>     >> If you mean to say that any application that uses Click packaging can't
>     >> just access any account it wishes, that's indeed true.
>     >
>     > Well, as more and more of the apps and scopes in the image are
>     > converted to Click packaging, this default exception for the
>     > "unconfined" label is going to become less useful.  It's also worth
>     > noting that the AppArmor label for click apps and scopes is going to
>     > change each time a new version is released, so there needs to be some
>     > way to add to the ACL for an existing account or account service.
> 
>     Note that while we add the full AppArmor label into the ACL, we compare
>     just the first two components; so, different versions of the same app
>     (or scope) will retain the permissions given to an older version.
> 
>     >> Scopes need to call this method as well, if they want to access the
>     >> account. IIRC, the plan was to have a scope-config tool which would do
>     >> that on their behalf.
>     >> (the other option is to go to the Accounts panel in the system settings,
>     >> click on the desired account and enable the application/scope from there)
>     >
>     > Scopes are not using the QML binding for Online Accounts (they are not
>     > GUI apps after all).  Could you explain what changes are needed for
>     > apps using libaccounts-glib/libsignon-glib to work with this system?
> 
>     Well, strictly speaking, the QML API we are exposing is also not GUI (it
>     doesn't depend on QtQuick or QtGui), but anyway we are also exposing a
>     Qt API for that. You can see it in use here:
>     http://bazaar.launchpad.net/~unity-team/unity-scopes-shell/trunk/view/head:/src/Unity/scope.cpp#L1259
> 
>     If your scopes are written in Go, I would strongly recommend you to wrap
>     the Qt library (it's basically just one method call); alternatively, you
>     could even use a raw D-Bus call (it's just one method), but that should
>     be considered only as a temporary hack, because we don't guarantee any
>     stability of the D-Bus API.
> 
> 
> We can't do a D-Bus call from a click package scope anyway can we?  I think dbus
> was explictly denied by AppArmor 
> 

A click package need only specify the 'accounts' policy group and use
policy_version 1.2 in the security manifest. This is true for both apps and scopes.

(Prior to apparmor-easyprof-ubuntu 1.2.21, the accounts policy group was
'reserved', however, online accounts now has Mir trusted session support so it
was moved to 'common' status. Also, recent versions of the click-reviewers tools
know that accounts is ok to use by both apps and scopes).

-- 
Jamie Strandboge                 http://www.ubuntu.com/

Attachment: signature.asc
Description: OpenPGP digital signature