launchpad-dev team mailing list archive

[Kees Cook <kees.cook@xxxxxxxxxxxxx>]

Hi,

I think whole-desktop authorization is a mistake, but let me get into some
background and thoughts on this, since there are a lot of well-made points
in this email thread and the proposed[1] policy that make my statement not
as clear-cut as it sounds. :)

First of all, I believe the gnome-keyring philosophy to be flawed, as it
discusses only the idea of secure-from-attack, and does not attempt to
consider discretionary access control. In other words, there is a
difference between malicious and accidental actions.

The notion of session tokens vs authentication tokens may dovetail well
into the timeout proposal as well. As long as applications negotiate a
session token for doing their work with a protected interface, and do
not use the primary authentication token the whole time, there is value
in security contexts.

For example, while I type my password into ssh to log into a remote
system, my password is used once and discarded after establishing the
session key for that SSH connection. Even malicious attackers cannot
get at that connection after[2] it is established.

The "security theater" mentioned in gnome-keyring is describing the "sense"
of security vs "actual" security. I think this is not as cut-and-dry as
that, since security is a continuum. For example, we haven't given up
on having separate users just because the Linux kernel has frequent
privilege escalation vulnerabilities.

What gnome-keyring's philosophy describes is worst-case security
protection against a persistent threat, that has access to the entire
desktop, catches your authentication passphrase as you type it into ssh,
etc. While this is certainly _a_ situations, it's not _all_ situations,
and I don't think security is all or nothing, which is what "theater"
implies to me. Even as they point out, work is being done to try to
contain these sorts of threats, and I think designing the LP integration
in a way to just kind of "gives up" on per-application security contexts
is a mistake.

An example of attempting access control in the face of potentially
non-perfect security is PolicyKit, which does attempt to have fine-grained
security contexts. It still suffers from some of the whole-desktop flaws
described, but it does attempt to implement access controls in the hopes of
solving the other problems as it evolves.

Access controls need more than just yes/no. The read/write/public/private
flags are currently very important to some users, especially those
users with privileges in LP. I think timeouts are especially important
to implement. Like with the SSH connection, if a malicious attacker
tries to immediately re-use a session token, it might fail if it has timed
out. It is required to wait for the authentication token instead, there-by
delaying potential attacks. From a pandemic-resistance perspective,
this delay has value.

For per-application access control, while I might let bughelper see
private bugs, I certainly don't want other LP-using applications to
see that data before I've had a chance to examine them. Additionally,
without the ability to define fine-grained access controls, it becomes
increasingly difficult to incrementally improve the desktop's defenses
against malicious attack. Designers of those protections would have no
way to see where the hard lines _should_ be drawn in the areas they may
not be domain experts in.

So, in summary:

 - It is a bug that gnome-keyring gives up its tokens to any application
   that asks with no way to manage or control it. Policy Kit has a better,
   though still somewhat flawed, way of handling authorizations.

 - Using sensibly short timeouts for session tokens as a default is good.
   I'm not opposed to making "forever" available for those that want it,
   but it should probably not be the default.

 - Defining and using per-application (or even finer) access control is
   good, though one must not claim that it is fully defensible against
   malicious attack -- making that claim is theater; having the ACL is
   currently good for accidental misuse, etc and has real value.

I think there would be value is discussing this more. Can we talk about
this at UDS maybe?

-Kees


[1] http://pastebin.ubuntu.com/499131/

[2] This hole has been fixed via the PTRACE protections in Maverick.
    Prior to that, a malicious program could attach to the running ssh
    and continue to use the session key to issue commands to the remote
    server. For more details, see /etc/sysctl.d/10-ptrace.conf on Maverick.
    (Which is, of course, modulo glaring kernel security vulnerabilities, etc.)

On Fri, Sep 24, 2010 at 07:27:28AM +1200, Robert Collins wrote:
> Thank you very much for sending this.
> 
> I want to address something up front, which I think there is perhaps
> confusion on.
> 
> I'm fine with the process you followed: as I said at the epic, we
> can't scale as a team if any part of the process bottlenecks, and
> talking to e.g. me first in any mandatory sense would bottleneck
> eventually.
> 
> I'm a strong believe in iterating and tweaking; as far as I'm
> concerned our process is working: something that sets of alarms had
> sufficient examination to be pulled out of the queue for closer
> examination.
> 
> I think it would have been a *good idea* for this particular thing to
> be socialised more, particularly with the Ubuntu security team and
> other Launchpad API developers, but I couldn't reliably describe in
> advance every patch that would need such socialisation.
> 
> Anyhow, its getting it now.
> 
> I've copied Kees on this, as a way to get him to eyeball it - he might
> not have time, or might want more of the Ubuntu security team to be
> involved, but I'll let Kees make that call :)
> 
> My specific concerns here are:
>  - will launchpad be safe for our System administrators to use?
>  - will it be safe for our archive administrators to use?
>  - will it be safe for any privileged user to use?
> 
> AFAICT the answer is no; with the intended design satisfied any rogue
> script can drive a tractor across all of launchpad as that user, and
> *thats* why I put the breaks on.
> 
> -Rob
> 
> On Fri, Sep 24, 2010 at 4:20 AM, Leonard Richardson
> <leonard.richardson@xxxxxxxxxxxxx> wrote:
> > Introduction: Can We Do As Well As Ubuntu One?
> > ==============================================
> >
> > Let's say you boot up your new Maverick system, fire up Rhythmbox, and
> > decide to buy some music from the Ubuntu One store. What happens?
> >
> > An application window pops up on top of Rhythmbox, asking you for your
> > Ubuntu SSO login and password so that you can get access to Ubuntu
> > One. Being a new user, you don't have an Ubuntu SSO account, so you
> > get a chance to create one. Once you have an account, you accept the
> > Ubuntu One T&C, and the application window secretly uses your
> > authorization to store a token on your computer.
> >
> > This token allows applications to use Ubuntu One under your name.
> > It's stored in the GNOME keyring. You never see the token, but it's
> > there, and usable by other applications.
> >
> > You buy your music, and then you get to work, writing some notes in
> > Tomboy. Once you're done, you decide to sync your notes to the cloud
> > using the Ubuntu One integration features of Tomboy. What happens?
> >
> > Well, nothing happens. The Ubuntu One token is available to *any*
> > application that uses Ubuntu One. You authorized Rhythmbox, but Tomboy
> > can use the token too. Tomboy grabs the token you created from
> > Rhythmbox from the GNOME keyring and syncs your notes.
> >
> > The Control Panel, desktopcouch, cloudserver, and every other
> > application that uses Ubuntu One can grab this token from the GNOME
> > keyring, without asking you, and access your Ubuntu One account.
> >
> > Uh-oh! Rhythmbox just crashed while it was playing your music! Now a
> > dialogue box pops up, asking you if you'd like to report a bug. You
> > would like to report a bug, so you go through a process that's pretty
> > similar to the process you went through when you wanted to buy some
> > music:
> >
> > A browser window pops up, and you're asked to log in to Launchpad, the
> > site that hosts the bug reports. You're able to log in using the
> > Ubuntu SSO account you just created, and then you get a message like
> > this:
> >
> >  The application identified as "apport" wants to access Launchpad on
> >  your behalf. Will you allow "apport" access to your Launchpad account?
> >
> >  * Yes.
> >  * No, thanks.
> >
> > You click "Yes", and Launchpad grants your computer a token that lets
> > apport use Launchpad on your behalf, without asking you every
> > time. This token is stored in the GNOME keyring, right next to your
> > Ubuntu One token.
> >
> > But of course you don't see the tokens. You just see that apport has
> > done its job and now there's a Rhythmbox bug in Launchpad with your
> > name on it. Now you're curious about Launchpad, so you poke around the
> > site.
> >
> > You decide that Launchpad is the perfect site to host the little open
> > source project you're working on, so you start a project and import
> > your source tree. And you discover there's an application called
> > Ground Control, which lets you integrate your Launchpad work into your
> > desktop.
> >
> > You install Ground Control, start it up, and... your browser opens
> > again.
> >
> >  The application identified as "Ground Control" wants to access
> >  Launchpad on your behalf. Will you allow "Ground Control" access
> >  to your Launchpad account?
> >
> >  * Yes.
> >  * No, thanks.
> >
> > What happened? How come Tomboy didn't need to ask you for permission
> > to access your Ubuntu One account, but Ground Control had to ask you
> > for permission to access your Launchpad account?
> >
> > This is a question that our users have been asking (albeit not in this
> > form) since the Launchpad web service was first released. We don't
> > have a good answer. It turns out there *is* no good answer. It's time
> > to change this.
> >
> > Authorize the entire desktop at once
> > ====================================
> >
> > I have a branch in review that needs some discussion. Here's the merge
> > proposal:
> >
> > https://code.edge.launchpad.net/~leonardr/launchpad/rename-grant-permissions
> >
> > I'm changing the social norms around Launchpad's OAuth token
> > authorization protocol, *as it's used on the Ubuntu desktop*, to make
> > it more like the system used by Ubuntu One. Instead of authorizing
> > individual applications (apport, Ground Control, etc.), the end-user
> > will authorize the Ubuntu desktop itself. The protocol itself is
> > unchanged; I'm simply reducing the number of times the end-user has to
> > go through it.
> >
> > Robert pulled the brake on my branch because he has legitimate
> > concerns about my process: I didn't use this list to hash out the
> > design, and the design has changed radically over the past couple
> > months. Fair enough. Let me present the stable design in public, tell
> > you who I've discussed it with, and try to convince you that it's good
> > on the merits.
> >
> > The ultimate purpose of this branch is to stop third-party developers
> > from writing horrible hacks that bypass the OAuth token authorization
> > protocol. These people are my customers. I can't stop them through
> > technical means, any more than music companies can stop *their*
> > customers from sharing songs with each other. But I can get my
> > customers back on my side, by improving the experience of the
> > "legitimate" alternative.
> >
> > I went through a couple iterations of a design in consultation with
> > these third-party developers, and with the Ubuntu desktop team
> > responsible for the Ubuntu Single Sign-On desktop app (that's the
> > thing that lets Rhythmbox and Tomboy connect to Ubuntu One). The
> > current iteration of the design is based on the fact that the GNOME
> > Desktop is a unified security context, and that our attempt to
> > partition OAuth tokens by application is nothing but security theater.
> >
> > I was shocked when I found this out, but it's true. See here for
> > details:
> >
> > http://live.gnome.org/GnomeKeyring/SecurityPhilosophy
> >
> > My goal is to improve the experience for desktop Ubuntu users by
> > getting rid of the security theater. When you're giving a website
> > (maybe Facebook or OMGUbuntu) access to your Launchpad account, our
> > current design is absolutely *not* security theater, and the current
> > design will continue to work in that context.
> >
> > Based on this revelation, I worked with the Ubuntu SSO team to develop
> > my third, and hopefully final, design. Here's a document that explains
> > my design in detail. You don't need to read more than the first four
> > sections, but I would appreciate it if you'd read those four before
> > continuing.
> >
> > http://pastebin.ubuntu.com/499131/
> >
> > On Tuesday I presented this document on a conference call with the
> > Ubuntu SSO team, Ubuntu technical architect Allison Randal, and Ubuntu
> > engineering manager Rick Spencer. We specifically talked about the
> > security implications of this design: what might happen if malware
> > running on your machine gets access to your desktop-wide Launchpad
> > credential.
> >
> > We reached a conclusion that's pretty common-sense: if you have more
> > to lose, you should be more careful. If you're a big-name Ubuntu or
> > Launchpad developer, and your computer is compromised by malware, and
> > the malware takes your Launchpad credentials and does horrible things
> > like releasing embargoed security bugs, then that's a really really
> > bad situation. But it doesn't really matter whether the malware does
> > its dirty work using an OAuth token for "Ubuntu desktop" or an OAuth
> > token for "Ground Control".
> >
> > It would also be really bad if malware got access to your Ubuntu One
> > account, but having different tokens for every app won't help. Because
> > of the design of X and GNOME, there is absolutely no way to prevent
> > malware running as you from getting access to your GNOME keyring (or
> > your home directory, where OAuth tokens were stored in earlier
> > versions of launchpadlib).
> >
> > The new design does not lessen security: it does induce a
> > feeling that something bad might happen because we're taking something
> > away. Which is exactly what you'd expect from the removal of security
> > theater.
> >
> > Side note for the above
> > -----------------------
> >
> > There is one use case in which the new system might be less secure
> > than the old system. In the old system, if malware is running on the
> > desktop of someone who uses apport to report bugs and has never used
> > another Launchpad-integrated application or run a Launchpad-integrated
> > script, that malware will have an effective Launchpad permission of
> > WRITE_PUBLIC. In the new system, that malware will have an effective
> > Launchpad permission of DESKTOP_INTEGRATION, which is the same as
> > WRITE_PRIVATE.
> >
> > I think it very likely that any privileged Ubuntu or Launchpad
> > developer who uses the Launchpad web service already has a
> > WRITE_PRIVATE token lying around their hard drive. It's a pretty
> > slender reed to hang your hopes on. I'm mentioning it only because
> > yes, there is a theoretical case in which the new system is less
> > secure.
> >
> > The same situation obtains right now with Ubuntu One--any app running
> > as you on your desktop can read and write all your data, no matter how
> > private it is. Many, many times have I heard variants on "if there's
> > malware on your system, you're screwed anyway", from the Ubuntu SSO
> > developers and from the third-party developers who I'm trying to
> > convince not to write horrible hacks.
> >
> > If you really don't trust your apps, you can have GNOME prompt you for
> > your password before every access to the token.
> >
> > Things I could go into
> > ======================
> >
> > This document's plenty long on its own, and it references other
> > documents that are also long, but there are a few more topics I can go
> > into more detail on if anyone's interested.
> >
> > 1. The two prior designs I worked out with the Ubuntu SSO team and the
> > third-party developers were equivalent, in security terms, to this
> > design. But they were also a lot more annoying to use and would have
> > required a lot more time to develop.
> >
> > 2. Developers can collude to implement this design without our
> > consent, by standardizing on a single OAuth consumer key and sharing a
> > single token across a given desktop. This branch creates a sanctioned,
> > safe way for developers to do what they can already do without us.
> >
> > 3. There are a couple difference between the way Ubuntu SSO does
> > things, and the way the Launchpad web service does things. Look into
> > this, and at first glance, it may look as though Ubuntu SSO *does*
> > authorize each app individually.
> >
> > Don't be fooled! Ubuntu SSO manages multiple web services (eg. Ubuntu
> > One and the software store), and it authorizes each *web service*
> > individually. Once a web service has been authorized, it can be used
> > by 200 different desktop applications without additional
> > authorization.
> >
> > Even this division is only done because each web service has its own
> > TOC that the user must agree to. It has no real effect on security.
> >
> > If we didn't want Launchpad to be an OpenID consumer, we could just
> > tie launchpadlib in to the Ubuntu SSO app. Then Launchpad's web
> > service would be one more service managed by Ubuntu SSO--and the
> > resulting system would have the same security properties as my branch.
> >
> > 4. There are some ways to improve the experience even more (such as by
> > auto-converting an Ubuntu SSO token into a Launchpad token if one is
> > found in the keyring), but this branch is a very easy first step that
> > will relieve a lot of pain.
> >
> > Leonard
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~launchpad-dev
> > Post to     : launchpad-dev@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~launchpad-dev
> > More help   : https://help.launchpad.net/ListHelp
> >
> >
-- 
Kees Cook
Ubuntu Security Team