launchpad-dev team mailing list archive

[Benji York <benji.york@xxxxxxxxxxxxx>]

On Thu, Sep 23, 2010 at 5:25 PM, Robert Collins
<robert.collins@xxxxxxxxxxxxx> wrote:
> On Fri, Sep 24, 2010 at 8:58 AM, Benji York <benji.york@xxxxxxxxxxxxx> wrote:
>> On Thu, Sep 23, 2010 at 4:15 PM, Gavin Panella
>> <gavin.panella@xxxxxxxxxxxxx> wrote:
>>> If I'm collaborating on, reviewing, or otherwise running a
>>> not-expected-to-be-evil-but-not-known-to-be-safe Launchpad API
>>> consumer, I'd like to be able to say "please use a read-only token
>>> this time instead of the desktop token" to reduce the possibility of
>>> mishap. Will that be possible?
>>
>> It's possible, but probably not what we really want to do.  Here are a
>> few scenarios:
>
> I think you have some hidden assumptions in your scenarios; I
> interpret them rather differently.
>
>> 1) the app is evil: you're screwed so it doesn't matter if you give it
>>   read-only or not
>
> Read-only public data is hardly screwed. Read-only private data may
> lead to disclosure but not to privilege escalation. 'Screwed' in this
> situation is unliked screwed in life: one can be a little bit screwed
> here, and a little bit is better than totally.

The Gnome Keyring folk's assertion
(http://live.gnome.org/GnomeKeyring/SecurityPhilosophy)
is that all processes running as a particular user in a desktop setting
share a single security context.  If they are right, then if one
application on my desktop has r/w access to LP, then any evil app on my
desktop can obtain r/w access (a.k.a. "screwed").

>> 2) the app only reads data: you're fine, but you would have been find
>>   with read/write access anyway
>
> Apps that only read data can be evil too, I don't quite see the
> distinction you're trying to draw.

Here and below I was assuming the app is non-evil.  A non-evil,
non-broken app that only needs to read will work just fine with r/w
access.
-- 
Benji York