-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iQIcBAEBCgAGBQJSHWFaAAoJEFHb3FjMVZVzG/8P/j9xW/8EwL0mFyiEGljybjIl
/B6If8bkxrbFU6lpQf+C2YCk9kdrVH3g3AonXf7ZUHFipl1G+yaE1EMFqSXAoFkx
LmJCYCbk6NZ5BsOs25OhZNdV36/t7OQH010L6wNuXHpGFThAGg1X+iYajHkVBUY+
uErUlHPz8V1CxZCrZI+tilWhvKlw0zDd0vfOCciCdsnDWyAuT22NtzNzP7YJeNoH
OpofzhVpfQeBE+Ny3AAHkIavSDcjz3RTx/8dNbjNT/238PN8EpdEaiNadGBP49/4
Tw29ujGFk+NLOcQkZbIGAKv4Xn0KXy0lMbXlSVceuDjHgN9OS9ZXSrGgL9YJ6SFV
ah8d3z+4s7kD7Ts8/4GOpqCQFXsg4H8YLljv6ASoyDNVRVHrQieVhSFZ769EJdIR
CRH/6EaT6EB3bidc98jbzKHlB7Ng2qen7H6TRIUWHlcCos6t9jKOa/Pch8MHr8CY
HScioF4LcV3rmLsissYTIVj8xchaGpcmGpDzXOAUMXIWYIK9B66Z8I6OWeg0tJdK
5rM+ACy6VVaT+rmGiZgUX1dyXDGgx59/FBIrki9YZQi0hhzOG504w9c3uskApBoh
OVc60QQh5K0nVyPEZJetQ/+FOLvq0lTF32efUwrjBDFv6e+kK4FN3oDRRtxEumXb
0Ar/OiAcHkiEduIA4vXS
=CbNx
-----END PGP SIGNATURE-----
On 08/27/2013 07:21 PM, John Johansen wrote:
> On 08/27/2013 03:38 PM, Jamie Strandboge wrote:
>>
>> This email is a long time coming-- we decided first to discuss the issues on the
>> mailing list to better understand the problem space and then have a UDS
>> discussion next time.
>>
To be clear on the initial email-- I was trying to bring up pain points and then
start off a discussion to come to common understanding on the current state so
we can figure out how to move forward for 14.04. With that in mind...
...
>> * it is possible that we could make it a requirement that scopes from
>> the appstore (ie, non-Canonical scopes) must be in their own process
> This is a REQUIREMENT to have security on these
I agree, which is why I brought this up later for all of us to agree to it. :)
>> * we can trigger manual reviews for scopes in general, or scopes that
>> need more flexible confinement. This is not optimal because we are striving
>> for as little code-reviews as possible in the app store because it just
>> doesn't scale.
> sure, but part of the idea is that we use confinement requirements to filter
> out what doesn't need review.
Yes, which is what I was getting at below. We should be able to do automated
checks if we lay some ground rules. Eg:
* no networking/less limited file permissions: automated check
* no networking/very limited file perms: automated check
* networking/very limited file perms: automated check
* networking/less limited file perms: MANUAL REVIEW
>> * we are able to revoke scopes from the app store if they are malicious
>> * appstore ratings will help self-regulate
>>
>> A few things not in our favor:
>> * scopes can by design do anything
> so can applications, its the sandbox that limits what they can do
>
Sure. The point I was trying to make is that scopes aren't (currently) designed
with confinement in mind. App store apps are. Traditional apps are not (but that
is a different conversation). Maybe by laying ground rules and having SDK
support, people will develop scopes with confinement in mind which, while not
solving all possible problems, might help.
>> * scopes can be aggregated in any number of ways
> sure and hence require the transitive closure permission of the aggregate
>
>> * due to aggregation, scopes are supposed to be able to communicate
>> with arbitrary other scopes
> Define arbitrary. We have to be able to limit what data and scopes they
> can communicate with at a policy level otherwise we can NEVER have none
> Canonical scopes.
>
> Sure the api can allow for arbitrary scopes but this has to be bound at
> run time by the policy
>
So, I was merely communicating what I was told is the current state. I brought
this up as a pain point that we need to figure out how to mediate.
>> * even local scopes may be required to access canonical.com/ubuntu.com
>> servers for side channel communications for recommendations
>>
> Again this must be controlable
I agree, but I brought this up separately as a pain point because while we can
have mediation here, AIUI the practicality is that many (most?) scopes will need
internet access so we need to consider it may be impractical to mediate network
access for scopes.
...
>> * can we agree to kill a scope and all of its children if the scope is disabled
>> or if the privacy setting is toggled to 'on'
> which privacy setting? Scopes will have more than one level of control, and just
> because privacy is on does not mean a scope may not be useful locally
I was referring to the global privacy setting that applies to networked scopes.
AIUI, there is a global privacy setting along with the ability to disable
individual scopes. I'm suggesting that when disabling an individual scope, we
should allow a well-behaved scope to shutdown gracefully, but follow up with
SIGKILL for a misbehaving scope and its children. We would do the same for
networked scopes when toggling the global privacy setting. I am not suggesting
we kill all scopes or local scopes that don't query a server.
>> * can we agree that scopes must use the unix domain socket ICE plugin? How can
>> we enforce this? (We should be able to prevent 'bind' for TCP and UDP using
>> AppArmor IPC mediation, but perhaps the scopes architecture enforces this)
> I don't think this is a hard requirement as noted above. We certainly need to
> mediate the communication channel but I don't think that is a requirement we
> need to foist on the scopes architecture.
I understand your point that we could solve this in other ways, however, the
scopes team has already implemented unix domain sockets and we will have IPC
mediation in 13.10, so for 14.04 I suggest we use what we've got. We can refine
if needed as we go forward.
>> * do we imagine that most scopes won't need filesystem access beyond what app
>> store apps typically would need? (essentially read access to the install dir
>> and write access to app/scope specific directories following the XDG base dir
>> specification). If so, we may be able to treat these scopes like ordinary
>> click apps (using a different AppArmor policy template though) where the
>> reviews are/will be automatic.
> I think that assumption is false. While I don't know what the scopes will be
> that want broader access, I can imagine they exist. At some time we will want to
> support this
>
> Perhaps we require such scopes to be audited, perhaps we can come up with something
> better.
This can't be an assumption-- I started with a question. ;) But seriously, I'm
just trying to understand if useful scopes can be made with these limitations.
See above about automated checks and ground rules. This is what I was trying to say.
The problem is that if we have too many scopes that need to be audited, we will
bottleneck because every new version will need a code review and we'll be right
back where we started with the ARB-- ie it didn't scale. My hope is that we can
come up with something that will scale.
>> * A big problem is that some scopes are expected to have access to other parts
>> of the filesystem. What is to stop a malicious scope from sending all the
>> user's data off to the internet? Would it be possible to say that if a scope
>> needed filesystem access like this, it is not allowed to connect to the
>> network at all? (ie, either have networking/very limited filesystem access or
>> no networking/less limited filesystem access). This seems quite tricky to get
>> right
> As a default maybe, but again I can see use cases for this. We need to be careful
> and audit things like this.
See ground rules, above.
>> * can we clearly define how aggregation works and how app store scopes are
>> intended to participate in aggregation? Would it help if we said that app
>> store scope can only be an aggragatee and not an aggregator? I don't have a
>> handle on aggregation yet to understand all the security implications....
>>
> Again that would be a major limitation, and could cut out useful scopes. I
> think it needs to be more along the lines of this scope can use these other
> scopes/data types as sources.
>
Maybe? I don't understand how aggregation is intended to work with scopes.
> Some of it can be preseeded some of it can be dynamic, and the user should be
> able to revoke such rights at any time.
>
I think the user has that ability simply by disabling scopes, but I don't know
what the user experience is intended to be with arbitrary combinations.
I definitely need input from the scopes team on the intent of aggregation and
how app developers are supposed to be able to leverage it.
>> = Issue #2: scopes privacy =
>> Related to confining scopes is enforcing network access based on the privacy
>> setting. The good news is that the new design for 14.04 doesn't require that
>> scope authors write code to honor the setting. Instead, if privacy is toggled
>> on, scopes simply aren't sent the request for data. Individual scopes can also
>> be toggled on and off so when a scope is disabled, it isn't sent any data. This
>> does not handle malicious scopes that access the network directly however-- ie,
>> a scope that ignores SIGTERM/SIGSTOP and keeps running behind the scenes to
>> shovel data over the network).
>>
> We have to confine each scope that could be malicious
>
Of course and we will, but this issue subtly different from confinement. Prior
conversations regarding scopes privacy suggested kernel level enforcement of the
global privacy setting. What I am working through here is that in 14.04 kernel
level enforcement of the global privacy setting is impractical, but the design
may suggest we don't need to enforce this privacy setting at the kernel level.
We enforce it at the master scope level. In all cases, app store scopes will be
confined.
>> To deal with both well-behaved and malicious scopes, there was the idea of
>> toggling between mostly-permissive AppArmor profiles to turn networking on and
>> off. Local scopes would always be off while smart scopes get toggled based on
>> privacy setting. This would work for 13.10 but is greatly complicated going
>> forward because networking is pretty much always needed for the side channel
>> communications.
>>
> Again, with a little more work this won't be the case
>
I don't understand. This is complicated in 14.04 because, AIUI, most scopes will
need internet network access (yes, even some local scopes). I'm not talking
about ICE TCP/UDP vs unix domain socket for the localhost bind for communicating
with the master scope. We won't have internet network access mediation for a
long time and when we do it will require secmark and ipsec, won't it?
>> Perhaps the design is sufficient to address scopes privacy though-- disabled
>> scopes aren't ever called/aggregated and the scopes architecture prevents
>> sending scopes data when the privacy setting is off, so a malicious scope can't
>> override being disabled or the user's privacy setting. We can add to that
>> SIGKILL for it and its children when it is disabled or the privacy setting is
>> toggled to on.
>>
> Are we saying that there won't be any scopes that are useful with the privacy
> setting toggled on? I can certainly think of lots of cases where a local scope
> search would be useful
>
That was not what I was saying at all. Disabled scopes are ones the user
disables, so the architecture allows for that (fine). For networked scopes, the
master scope does the global privacy setting enforcement-- ie, it doesn't send
data to networked scopes. Local scopes aren't affected by the privacy setting.
The complication in all of this is that in 13.10 and earlier, local scopes did
not need network access and networked scopes did. 14.04 complicates this because
at least some local scopes may need to communicate with canonical.com/ubuntu.com
(please correct me if I'm wrong). This is a pain point I wanted to discuss
because it blurs the line between local and networked scopes and makes it quite
difficult to differentiate between the two for both issues I brought up:
confinement and enforcing privacy. Perhaps it would make sense to bring back the
difference-- networked scopes are allowed to directly access the network and
local are; local scopes use a proxy process for these side-channel
communications. This could potentially bring back kernel level enforcement of
the global privacy setting as well as cleaning up apparmor policy and mediation
significantly. The proxy would enforce where the side-channel communications
went (ie, to canonical.com/ubuntu.com) and in theory could also be configurable
to allow/disallow such communications at all (eg, honoring the privacy setting
but otherwise letting the local scopes do what they need to).
Michi, Thomas and Thomas-- is my understanding of the 14.04 architecture accurate?
--
Jamie Strandboge http://www.ubuntu.com/
