Created attachment 111019 [details] [review]
disable dialogs by default unless special configure option is passed

Hi, we use this patch in Fedora now and I'd like to see it upstreamed; let me know if there's anything that needs to be improved or changed.  

One thought I had is to remove the configure option; I don't think asking the user this sort of thing is a good idea in any situation, and it would be simpler to just remove it entirely.

I agree, it's not safe at all. Any "normal" friend of mine would just push the button in "always allow". Or ask me and I'd say "just press always allow".

But regarding your SELinux comment, wouldn't this be a task for PolicyKit?

(In reply to comment #0)
> The "Allow program X to access keyring Y" dialogs do not work.  People see them
> in *completely normal* situations like using NetworkManager for the first time. 

This statement is accurate only if you replace "like" with "only". E.g., on a properly configured system (ignore crap like prelink for a while) you'd _only_ see this the first time some application is using the keyring. Do you agree with this?

So I think a better patch includes gnome-keyring maintaining a whitelist directory of what applications are allowed to use (certain parts of?) the keyring. Then NetworkManager and other users (e.g. seahorse) can simply drop (.ini) files in that directory. 

(Initially we can use the exe-path, with time we can move to security context once MLS, secure toolkits, secure windowing systems, free ponies for everyone  etc. is in place in 1000 years.)

I hear free ponies are next on the list so no worries there.

I agree with David here. Allowing every app to access the keyring makes its use a bit pointless. I wouldn't want some random application accessing the keyring unless I allowed it to. There can be untrusted applications, and they should be treated with caution.

I suggest the following:

* maintain a pluggable [1] whitelist of allowed apps

* ask only for apps not in that list

* remove the ability to "always allow" for the above step

[1] - pluggable means that an rpm package installed from the root account should have no trouble adding itself to that list. Think something along `polkit-auth --grant foo --app bar`, not something along `for i in /home/users/*; do ...`

On prompting in any form: any malicious code in the desktop today can simply wait for the dialog to appear and click "Allow" programatically.  There are Windows trojans that do this for the firewall dialogs, for example.  So besides the fact that only operating system developers can (semi) reliably answer the question, it does not work.

On the whitelist of allowed applications; what stops a malicious program from doing env LD_PRELOAD=myevil.so /path/to/trusted-app?  Answer: Nothing right now.  What SELinux does is cause glibc to enter a domain transition mode, so if two apps are in separate security domains, things like LD_PRELOAD are dropped.

If GNOME wanted to make some sort of hackish application whitelist, issues like that would need to be solved or it would just be fluff.

Bastien: Even without this dialog, the keyring still serves as an API and central point for storing passwords, which is quite useful.  It gives us the ability to implement a stronger system later without having to modify applications.

(In reply to comment #8)
> On prompting in any form: any malicious code in the desktop today can simply
> wait for the dialog to appear and click "Allow" programatically.  There are
> Windows trojans that do this for the firewall dialogs, for example.  So besides
> the fact that only operating system developers can (semi) reliably answer the
> question, it does not work.

Then deny any non-whitelisted apps, instead showing a window asking to file a bug.

> On the whitelist of allowed applications; what stops a malicious program from
> doing env LD_PRELOAD=myevil.so /path/to/trusted-app?  Answer: Nothing right
> now.  What SELinux does is cause glibc to enter a domain transition mode, so if
> two apps are in separate security domains, things like LD_PRELOAD are dropped.

Having a qualified whitelist does not rule out stuff like SELinux, AppArmor and what-not. I agree relying on paths is not enough as for example a plugin could exploit the trusted state of the host application (this becomes a real problem once apps integrate a "download plugins" functionality). Ideally we should depend on stuff like SELinux contexts but SELinux is not enabled on most of the machines.

> If GNOME wanted to make some sort of hackish application whitelist, issues like
> that would need to be solved or it would just be fluff.
> 
> Bastien: Even without this dialog, the keyring still serves as an API and
> central point for storing passwords, which is quite useful.  It gives us the
> ability to implement a stronger system later without having to modify
> applications.

Removing that dialog on the other hand takes away the security for *me*. In the past I was presented with an option to deny access, now every script can just read my passwords.

(In reply to comment #9)

> Then deny any non-whitelisted apps, instead showing a window asking to file a
> bug.

We're agreed, that is the right thing to do.

> Having a qualified whitelist does not rule out stuff like SELinux, AppArmor and
> what-not. 

My point was that the whitelist as proposed does not work because of LD_PRELOAD and ptrace, as a very start.

> Removing that dialog on the other hand takes away the security for *me*. In the
> past I was presented with an option to deny access, now every script can just
> read my passwords.

Any malicious code running as your uid (and without something like SELinux) could *already* read your passwords, by auto-clicking the Allow dialog, LD_PRELOAD/ptracing an already allowed application, etc.

(In reply to comment #8)
> On prompting in any form: any malicious code in the desktop today can simply
> wait for the dialog to appear and click "Allow" programatically.  There are
> Windows trojans that do this for the firewall dialogs, for example.  So besides
> the fact that only operating system developers can (semi) reliably answer the
> question, it does not work.
> 
> On the whitelist of allowed applications; what stops a malicious program from
> doing env LD_PRELOAD=myevil.so /path/to/trusted-app?  Answer: Nothing right
> now.  What SELinux does is cause glibc to enter a domain transition mode, so if
> two apps are in separate security domains, things like LD_PRELOAD are dropped.

This is all true. FWIW, bug 531609 comment 9 has more details on some problems that need solving.

> If GNOME wanted to make some sort of hackish application whitelist, issues like
> that would need to be solved or it would just be fluff.
> 
> Bastien: Even without this dialog, the keyring still serves as an API and
> central point for storing passwords, which is quite useful.  It gives us the
> ability to implement a stronger system later without having to modify
> applications.

However, security issues aside, it still may be kinda useful to get the prompt. Suppose I have to IM clients using a well-defined scheme for storing IM passwords. If I store IM passwords with IM client A, should we just allow IM client B to access them without the users consent? Maybe we just should.

I'm bouncing back and forth on this. I guess, as long as we can implement this later once we have a secure MLS desktop I guess it's fine to remove the dialog. It's pretty much snakeoil in the desktop people ship today.

     David

(In reply to comment #10)
> (In reply to comment #9)
> > Having a qualified whitelist does not rule out stuff like SELinux, AppArmor and
> > what-not. 
> My point was that the whitelist as proposed does not work because of LD_PRELOAD
> and ptrace, as a very start.

I still believe it's fairly harder to put two executable elf files (at least the library has to be an elf shared object and has to match your glibc and architecture) then convince the user to run one of them than to simply post a line of shell/python code to paste on one of the forums.

> > Removing that dialog on the other hand takes away the security for *me*. In the
> > past I was presented with an option to deny access, now every script can just
> > read my passwords.
> Any malicious code running as your uid (and without something like SELinux)
> could *already* read your passwords, by auto-clicking the Allow dialog,
> LD_PRELOAD/ptracing an already allowed application, etc.

That's true and is exactly why I don't run stuff that didn't come from my distro (or an ISV that I trust and pay). I do however know users who just try every code snipped posted in forums while trying to solve some problem.

These dialogs are even more broken with applications written in python, C# or other such languages. The application executable will be the some for a whole swath of applications.

See bug #342144

Also (though not strictly related), now that gvfs does its prompting from a daemon, all applications *sort of* share the same password access for network passwords. That is, they can all access the share, whereas before each additional application would need to be approved. 

And that's a good thing!

This dialog sucks, and provides a false sense of security. Even the whitelist provides a false sense of security. It seems even the whitelist which forces a 'deny' for all else, provides a false sense of security (LD_PRELOAD, python apps above).

BTW, Mac OS has these prompts. They seem to be able to properly do this properly because their applications are somehow uniquely identifiable. They don't just rely on file system paths to do their ACLs in key chain. 

I was toying with the idea of somehow having a gconf option, but that's broken, as a malicious program can just disable any enabled prompts in gconf.

So that brings us back to the patch. I'd include it. 

However for now, we won't remove much of the internal acl periphery, as David suggested, in the hopes that one day we'll be able to switch it on in a secure way for certain people. 

Thinking about it more, we already have a 'default deny' policy available for applications that would like to use it. This is via the GNOME_KEYRING_ITEM_APPLICATION_SECRET flag.

An application can set the GnomeKeyringItemType to GNOME_KEYRING_ITEM_GENERIC_SECRET | GNOME_KEYRING_ITEM_APPLICATION_SECRET, and the password will only be accessible to the application that created. No prompts are ever issued in this case.

There are still obviously security holes via LD_PRELOAD, and problems with using the full application path as the authorization (ie: scripting languages always having the same executable path). However I have faith that these can be solved in the future with the progress that is being made on secure application contexts, etc...

The patch broke the above feature and a few other little corner cases. I've committed a conservative (and fixed) version of this patch. Specify --disable-acl-prompts to ./configure.

FWIW, that the current confirmation is quite non-helpful. Since *every* user will see those dialogs a couple of times (network-manager, empathy, epiphany, seahorse, you name it...), everyone will get used to just click them away. The bad thing is, if there is really an app which isn't supposed to access the keyring, then the user won't really notice that and just click it away anyway.

I agree that the principal idea of that dialog is a good one to prevent trojans from accessing your keyring. However, with today's desktop security model that just doesn't work. LD_PRELOAD has already been mentioned, another one is that a trojan ptrace()s a legitimate application like nm-applet and thus can access the keyring through the already given permission without even triggering the confirmation question.

So I vote for disabling the dialog until we actually have the means to make it work correctly.

I believe this patch got in, but it's not the default so you need to pass --disable-acl-prompts or something like that.  

(Though I do believe that if the majority of vendors are passing a flag it should be the upstream default)

I agree this is a problem, but there is obviously more than one side. Just one example: http://bugzilla.gnome.org/show_bug.cgi?id=551036

I don't quite see how 551036 and this are related? 551036 is about encrypting the keyring contents with your password (essentially), while this is about a simple, but rather pointless yes/no question from the keyring about access for a particular application.

It's an example of someone asking for *more* restrictions. Turning the yes/no prompt into a sudo-style type-your-password prompt. 

This is what Mac OS X does. To grant an application access to a password in the KeyChain it prompts you for your login password. 

It also has a list of signed trusted applications that can access whatever password they like... 

Going back to the origin of this bug - the allow/deny can't be implemented securely on our platform without very significant engineering work, and honestly I doubt it's very secure on OS X either.

We shouldn't sell people snake oil.  Protect your account with a screensaver and/or encrypted disks.