Thanks for reviewing the wiki. I'll add your concerns to that section. If I'm understanding correctly, you are arguing for a flat "hierarchy", peers in the debian sense. The analogous idea in the B2G world would be that Mozilla, telcos, company foo could all run their own stores. If a user doesn't like the policies of the existing stores, they can start their own. However, there wouldn't be a way for Mozilla to say, "I trust store bar" so I'm going to give them the same privileges as me.
The "peer" model sounds find to me. It still allows multiple stores. The selfhost issue Jonas brought up doesn't seem to apply if the packages are signed. I could host my own app and have it on the store at the same time. There is still the question of granting permissions. I'm not sure if the store is the proper entity to decide whether an app can obtain permission X/Y/Z. David Chan ----- Original Message ----- > From: "lkcl luke" <luke.leigh...@gmail.com> > To: "ptheriault" <ptheria...@mozilla.com> > Cc: dev-weba...@lists.mozilla.org, "David Barrera" > <dbarr...@ccsl.carleton.ca>, "Fabrice Desré" > <fabr...@mozilla.com>, "Lucas Adamski" <ladam...@mozilla.com>, "Jonas > Sicking" <jo...@sicking.cc>, > dev-security@lists.mozilla.org, cjo...@mozilla.com, "Jim Straus" > <jstr...@mozilla.com>, "Mozilla B2G mailing list" > <dev-...@lists.mozilla.org> > Sent: Wednesday, March 14, 2012 4:53:56 PM > Subject: Re: [b2g] OpenWebApps/B2G Security model > > review: > https://wiki.mozilla.org/Apps/Security#Trusted_store_with_permissions_delegation > > (thank you to david for documenting this stuff, yeah!) > > > "A store (parent) may permit a trusted store (child) to grant a > subset > of parent's permissions" > > no. this is a very bad idea. ok. maybe it is, maybe it isn't, but > it has a couple of implications which need to be considered. > > * delegation implicitly means that you have a hierarchical > permissions > system. hierarchical permissions systems have a bit of a problem in > that once the genie is out of the bottle, you can't really get it > back > in. this is why the FLASK security model is *NOT* based on > "hierarchical permissions". delegation is fundamentally and > diametrically opposed to the principles behind FLASK (although you > could theoretically express a hierarchical permissions system _using_ > SE/Linux, if you really really wanted to). > > * thinking from the perspective of debian package maintenance, you > don't see them "delegating", do you? in 20 years, nobody's come up > with the idea of "delegating" package maintenance. it's simply not > needed. why? because... > > * ...there is the concept of adding *peer* stores (in debian > packaging > terms). take a look at http://debian-multimedia.org. note on there, > it says, "The first package to install is debian-multimedia-keyring. > Since Squeeze you can install this package with apt-get but you need > to presse Y when the package ask what to do and do not press return." > > * then there are mirrors. mirrors just copy pre-signed packages. > you > don't need to "delegate", you just... do it. they're signed. > they've > been vetted. there's no problem. they're tamper-resistant. > > l. > _______________________________________________ > dev-security mailing list > dev-security@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security > _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
