Merge lp:~thomas-voss/trust-store/fix-1504022 into lp:trust-store/15.04
| Status: | Merged | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Approved by: | Alberto Mardegan on 2015-11-24 | ||||||||
| Approved revision: | 141 | ||||||||
| Merged at revision: | 140 | ||||||||
| Proposed branch: | lp:~thomas-voss/trust-store/fix-1504022 | ||||||||
| Merge into: | lp:trust-store/15.04 | ||||||||
| Prerequisite: | lp:~thomas-voss/trust-store/integrate-xdg | ||||||||
| Diff against target: |
1270 lines (+687/-167) 17 files modified
CMakeLists.txt (+1/-1) debian/control (+1/-0) po/trust-store.pot (+10/-11) src/CMakeLists.txt (+7/-0) src/core/trust/daemon.cpp (+1/-1) src/core/trust/mir/agent.cpp (+22/-42) src/core/trust/mir/agent.h (+44/-16) src/core/trust/mir/click_desktop_entry_app_info_resolver.cpp (+139/-0) src/core/trust/mir/click_desktop_entry_app_info_resolver.h (+49/-0) src/core/trust/mir/prompt_main.cpp (+44/-41) src/core/trust/mir/prompt_main.h (+16/-4) src/core/trust/mir/prompt_main.qml (+66/-30) tests/CMakeLists.txt (+20/-0) tests/click_desktop_entry_app_name_resolver_test.cpp (+75/-0) tests/mir_agent_test.cpp (+131/-21) tests/share/applications/valid.pkg_app_0.0.0.desktop (+56/-0) tests/test_data.h.in (+5/-0) |
||||||||
| To merge this branch: | bzr merge lp:~thomas-voss/trust-store/fix-1504022 | ||||||||
| Related bugs: |
|
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Matthew Paul Thomas | design | Approve on 2015-12-07 | |
| Tyler Hicks | Approve on 2015-12-01 | ||
| Alberto Mardegan (community) | 2015-11-24 | Approve on 2015-11-24 | |
| PS Jenkins bot | continuous-integration | 2015-11-24 | Pending |
|
Review via email:
|
|||
This proposal supersedes a proposal from 2015-11-20.
Commit Message
Add interface mir::AppNameRes
mir::AppNameRes
to localized application names.
Description of the Change
Add interface mir::AppNameRes
mir::AppNameRes
to localized application names.
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:141
http://
Executed test runs:
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Tyler Hicks (tyhicks) wrote : | # |
Hello - Thomas had asked for a security review and I just took a look at the code.
The code itself looks nearly perfect. I have a couple questions below but they're minor.
I'm mainly concerned about the concept of using the localized Name of the desktop file in a trust prompt. For something like a click app that comes from an untrusted developer, we have no idea if the localized name in their provided desktop file is an accurate translation or a malicious translation intended to trick the user into granting their app access. I don't know of any logic that could be used in the click reviewers tools to verify that the translations are non-malicious. How do we handle such a situation?
As for the code, I have a couple questions/comments:
1) What UID does resolve_
2) The external XDG stuff that you wrote is a nice idea. I'd recommend packaging it up as a library so that it can be reused in a controllable fashion instead of copying and pasting the code into all of the projects that want to use it.
| Tyler Hicks (tyhicks) wrote : | # |
After speaking with jdstrand, he explained why the click reviewers tools don't currently verify the Name field of a desktop file. The desktop file name field can't be forced to match the click package name because the desktop file name should be "pretty" while the click package name is alphanumerics and '-'.
Because of this, I don't see how the desktop file name field can be trusted enough to be used in trust store prompts. :/
| Thomas Voß (thomas-voss) wrote : | # |
Hey Tyler,
thanks for the detailed review and your comments. Let me first try to clarify on the use of the localized name in trust prompts. I actually raised the same issue as you, and it turns out that we are "vulnerable" to applications faking their identity in a couple of places throughout the system. First and foremost: Unity itself relies on the .desktop file entry for displaying the name. We might want to fix the default approach for handling localized application names meant for human consumption in snappy, though.
One possible way to resolve the issue is by altering the prompt to show the localized name alongside the actual application id. Ideally, we would have an expendable field "Details" as part of the prompt containing in-depth information about the request, at the very least the actual app ID together with the UID (and the human-readable user name).
(@1:) The function always runs under the actual user. I will however add a check to make sure that the current user id matches the user id of the request. If not, we will return early, and deny the request.
(@2:) Sure, happy to. I mainly added the external code here to guarantee a swift landing. I will do the packaging and carry out the requesting asap, but would like to make sure that a fix for this bug is not blocked by package/MIR review processes.
| Thomas Voß (thomas-voss) wrote : | # |
One other idea to further clarify the identity of the app might be to include its official icon. At the very least, this would make it easier for the user to associate the source of the trust request with what is visible in the dash and in the launcher.
| Thomas Voß (thomas-voss) wrote : | # |
I reported the potential privilege escalation issue in https:/
| Sebastien Bacher (seb128) wrote : | # |
@Tyler, note that the current situation is not any better, the prompt are using the name of the hook included in the click, which is also not restricted...
Having the appid mentioned looks like a good idea to me though
| Thomas Voß (thomas-voss) wrote : | # |
> @Tyler, note that the current situation is not any better, the prompt are
> using the name of the hook included in the click, which is also not
> restricted...
>
I think that's an issue with our review tools tbh. The trust store relies on apparmor to query the profile name. With that, if an app can just request any name in there, we have got a problem from my pov.
> Having the appid mentioned looks like a good idea to me though
| Tyler Hicks (tyhicks) wrote : | # |
Thomas, I'm not sure that you need to add a user ID check. I was just curious what UID the code was expected to be running in. I'm happy enough with your answer that it runs as the user.
If you think the XDG code will be reused in other projects, it'd be good to package up separately.
| Tyler Hicks (tyhicks) wrote : | # |
> @Tyler, note that the current situation is not any better, the prompt are
> using the name of the hook included in the click, which is also not
> restricted...
>
> Having the appid mentioned looks like a good idea to me though
Yes, I think the appid approach has a chance of greatly improving the situation.
| Matthew Paul Thomas (mpt) wrote : | # |
The standard permission prompt message is of the form
<appname> wants to access <property>.
for example
Frobnicator Turbo wants to access your location.
so the attack you have in mind is for Frobnicator Turbo to pretend to be another app:
Browser wants to access your location.
Especially while people are used to hardly anything happening in the background, this might often fail. People would think, "Huh? I'm not using Browser at the moment. Why is it asking me now?"
Showing the app icon would help now, but it would lose its effectiveness once bug 1453795 is fixed.
Including the application id might protect geeks, but I expect most people would ignore it, or think it was a bug, on the grounds that it looks like code. If it was embedded in the prompt text,
<appname> (<appid>) wants to access <property>.
then an app could even explain it away with a devious name:
Browser (downloadable from
producing the prompt
Browser (downloadable from (frobnicator-
The profusion of TLDs leaves that plausible even to geeks who aren't familiar with the exact format of the prompt. Few would notice the unmatched bracket. So if it's included at all, I think it should be secondary text, like in the "Details" section for PolicyKit prompts. <https:/
Meanwhile, an app could do much more devious things with its name. Maybe we can address these at the same time, or maybe they need to be tackled separately. For example, an app could give itself a name something like
Browser wants to access only your bookmarks. It does not
which would produce prompt text of the form
Browser wants to access only your bookmarks. It does not wants to access your location.
This would be slightly ungrammatical ("does not wants"), but would still fool many people.
How to mitigate this? We could put the app name in quote marks:
“Browser wants to access only your bookmarks. It does not” wants to access your location.
But then the app could jimmy its own opposing quote marks into its name:
Browser” wants to access only your bookmarks. It does “*not*
producing the only-slightly-
“Browser” wants to access only your bookmarks. It does “*not*” wants to access your location.
(This idea adapted from <https:/
(We couldn't prevent that by banning use of quote marks, because there are many other Unicode characters that look like quote marks, including apostrophes: Baldur’s Gate, Sid Meier's Civilization, Tony Hawk's Pro Skater 2, etc.)
We could limit the length of app names to something like 30 characters:
“Browser wants to access only
That would put the kibosh on those obfuscation attacks ... in most languages. Not in kanji ones, unfortunately:
浏览器要访问您的书签。
But maybe mitigating the attack in most but not all languages is better than mitigating it in none of them.
We could put the app name in color, while the rest of the text is the normal UI color. But apparently that hasn't stopped malware in the past. <https:/
Perhaps a har...
| Thomas Voß (thomas-voss) wrote : | # |
> The standard permission prompt message is of the form
> <appname> wants to access <property>.
> for example
> Frobnicator Turbo wants to access your location.
> so the attack you have in mind is for Frobnicator Turbo to pretend to be
> another app:
> Browser wants to access your location.
>
> Especially while people are used to hardly anything happening in the
> background, this might often fail. People would think, "Huh? I'm not using
> Browser at the moment. Why is it asking me now?"
>
> Showing the app icon would help now, but it would lose its effectiveness once
> bug 1453795 is fixed.
>
> Including the application id might protect geeks, but I expect most people
> would ignore it, or think it was a bug, on the grounds that it looks like
> code. If it was embedded in the prompt text,
> <appname> (<appid>) wants to access <property>.
> then an app could even explain it away with a devious name:
> Browser (downloadable from
> producing the prompt
> Browser (downloadable from (frobnicator-
> location.
> The profusion of TLDs leaves that plausible even to geeks who aren't familiar
> with the exact format of the prompt. Few would notice the unmatched bracket.
> So if it's included at all, I think it should be secondary text, like in the
> "Details" section for PolicyKit prompts.
> <https:/
>
> Meanwhile, an app could do much more devious things with its name. Maybe we
> can address these at the same time, or maybe they need to be tackled
> separately. For example, an app could give itself a name something like
> Browser wants to access only your bookmarks. It does not
> which would produce prompt text of the form
> Browser wants to access only your bookmarks. It does not wants to access
> your location.
> This would be slightly ungrammatical ("does not wants"), but would still fool
> many people.
>
> How to mitigate this? We could put the app name in quote marks:
> “Browser wants to access only your bookmarks. It does not” wants to access
> your location.
> But then the app could jimmy its own opposing quote marks into its name:
> Browser” wants to access only your bookmarks. It does “*not*
> producing the only-slightly-
> “Browser” wants to access only your bookmarks. It does “*not*” wants to
> access your location.
> (This idea adapted from <https:/
> injected.png>.)
>
> (We couldn't prevent that by banning use of quote marks, because there are
> many other Unicode characters that look like quote marks, including
> apostrophes: Baldur’s Gate, Sid Meier's Civilization, Tony Hawk's Pro Skater
> 2, etc.)
>
> We could limit the length of app names to something like 30 characters:
> “Browser wants to access only
> That would put the kibosh on those obfuscation attacks ... in most languages.
> Not in kanji ones, unfortunately:
> 浏览器要访问您的书签。
> But maybe mitigating the attack in most but not all languages is better than
> mitigating it in none of them.
>
> We could put the app name in color, while the rest of the text is the normal
> U...
| Thomas Voß (thomas-voss) wrote : | # |
> Thomas, I'm not sure that you need to add a user ID check. I was just curious
> what UID the code was expected to be running in. I'm happy enough with your
> answer that it runs as the user.
>
You were raising a perfectly valid issue. Requests *should* always be handled by user-specific store instances. The branch I proposed ensures that this actually happens or it fails loudly :)
> If you think the XDG code will be reused in other projects, it'd be good to
> package up separately.
Yup, I will tackle it next after this landing. That will also include changes to account for snappy/
| Thomas Voß (thomas-voss) wrote : | # |
Please find a screenshot of the current version here: http://
- 142. By Thomas Voß on 2015-11-26
-
Address comments in review and implement new prompt design.
- 143. By Thomas Voß on 2015-11-27
-
Ensure that rendering is consistent with app icon rendering on launcher/dash.
- 144. By Thomas Voß on 2015-11-27
-
Update pot to account for string changes.
| Matthew Paul Thomas (mpt) wrote : | # |
A couple of nitpicks, but the screenshot looks good otherwise.
- 145. By Thomas Voß on 2015-11-30
-
Change color of negative action to neutral, see:
https://developer. ubuntu. com/api/ apps/qml/ sdk-14. 10/Ubuntu. Components. UbuntuColors/ #lightGrey- prop
Fix apostrophe to be a real typographic apostrophe. - 146. By Thomas Voß on 2015-11-30
-
Align with app scope display of icons, see:
https://code.launchpad .net/~cimi/ unity8/ new-shadows- 1.3/+merge/ 271611
| Tyler Hicks (tyhicks) wrote : | # |
Looks good to me. Nice work on finding a better solution!

A couple of inline comments, I'm not convinced that this way of finding the desktop files is reliable.