I was reading Knowing who's asking when I thought of something. If I am right the compositor should be the only program that can access another programs display. So if you create a layer over the applications window that asks for the permission instead of an own window that asks for permission the user can be sure it is the compositor that is asking for permission instead of some third party application that might be spoofing.

I realize that the application can try to reproduce that layer which makes it still possible to spoof. But the main point is that the compositor should do the authentication request in a way only the compositor can. For instance on laptops you can let the webcam light blink to show that it is the compositor actually speaking, because you need permissions to do that, that at that moment, only the compositor has. Or otherwise you can let the compositor take a screenshot of the screen to show the user to make sure it is the compositor.

I am no expert so I expect you will have really easy ways of getting around these things, Or you have alread discussed some of these ideas, I don't know.

Speaking on the runtime-binary problem of things like perl, python, Java, etc. -  that's a really hard problem. In the case of shell scripts, it may be possible to take a hash of the source itself. How do we deal with process trees, where the parent process is /bin/bash and the child is /bin/foo?

For Java, you can connect at runtime and inspect its complete classpath. You could take a hash of every binary JAR on the classpath. You could probably try to get the "main" class, but then you have Java libraries like the Tanuki Soft Wrapper that exist only to run other java programs, so every app using that would appear as the tanuki soft wrapper. You could use that same connection mechanism to get a stacktrace of the main thread and analyze everything there, but we're starting to get into some very esoteric solution spaces at this point.

For Perl and Python, I don't know how to mitigate the issues, but I'm sure like both bash and Java, there are nuances that complicate any possible solution.

On another topic: if you have the compositor generate a secret, you could use one of those random-bits-to-icon (like gravatar) type systems and have a path for a compositor-trusted application to get the icon for display. Console apps could figure out a textual way to represent the information. It would be very easy for a user to confirm that an icon in a request window matches the icon displayed in, for example, their panel.

Thanks for this very long blog post on the issue, and thank you for pursuing granular runtime permissions. I hear the Android security model talked about a lot by many as a model for security design, but I have to say, please no. Android's all-or-nothing model means I can't use a limited set of functionality of applications - I have to find something else that implements without the extra feature that requires extra priveleges. Sure, runtime privs imakes app authors' lives harder - we can't assume we won't get a permission denied error when we do something - but ultimately I think it's the better model.

One more topic. I'm highly interested in where we can take things with LXC and utilities like systemd-nspawn. It makes sense to me to run apps in isolated environments. Per the famous XKCD, where the user is walled from the system, but everything running in the context of the user account can touch everything - and for a user, that is literally everything. This works hand-in-hand with your UI authorization/authentication mechanisms, but goes beyond that. I'm imagining things like a virtual filesystem, where we can authorize apps to say, read our ~/Documents folder, but if it tries to write to ~/Documents, we can push an alert through the systems you are proposing. And then we can "remember" our authorizations, and have a consistent way to manage them. Managing them and making that persistence mechanism secure will also be a challenge.

Thanks again!

@BlackWolf, AnonC (the image part)

Yes indeed, doing stuff only the compositor can do is a good method for trust signalling... provided that the user will pay attention to it and will understand that this is a compositor-only thing. I've seen my share of lay users (quite rightfully I must say) sticking some cardboard or paper over their laptop webcam when they don't use it because they don't trust apps to not spy on them. The same users have extremely insecure data handling habits and privacy settings on FB, etc. For me this is good anecdotal evidence that users do need and want security and privacy but have a very crude understanding of what their apps can and cannot do. 

That's why I like the idea of a secret image rather than just behavioural signals that cannot be linked back to the compositor. The image is something the user recognises, hence it's more likely to be a good trust signal. I'm not confident in just showing the contents of windows or a screenshot, etc. because if an attacker suspects you only have their window open and maximised, they can fake it (or generally speaking because it'd be displayed at a reduced size when it'd be hard to recognise spoofs).

AnonC, I must say I really like the suggestion of using Identicons (I suppose https://en.wikipedia.org/wiki/Identicon are what you meant)! This'd avoid the user having to spend time choosing a picture among a pool, as the pictures could just be generated when the OS is being installed Attacks against this would be very hard, however one would need to evaluate their memorability. I did a quick search and only found a MSc thesis (here) that does a comparative study of various identicon schemes for immediate recognition (not over time which is what we'd need).

@AnonC 

In retrospective I think the problem is somewhat different for shell scripts and interpreted apps in general (e.g., Java, Python). Scripts are meant to be run on the system and with user privileges, so I think a script run by an app should inherit the app's privileges and a script run by the user should inherit the user's. The user may want to white-list their terminal if they're heavy terminal users, otherwise they might get the occasional prompt or whatever. I don't mind much but at the end of the day you probably don't wanna sandbox terminals. Just put them out of the reach of other apps.

As for interpreted languages, it's expected that with sandboxes we'll have bundles of binaries/interpretable scripts bundled within one sandbox and so essentially with one identity. So, I could give privileges to the JVM in the Sandbox 'Eclipse' or the Python in the sandbox 'Exaile'. There are some difficulties however. Many apps nowadays have plugins that make them compatible with other apps and allow combining their features. For instance, Exaile has an ExFalso plugin that runs ExFalso embedded into an Exaile GUI -- allowing editing of the music files' tags. In such a case, is it Exaile or ExFalso asking for the permission? How does Exaile call ExFalso and bend it into its GUI? How does ExFalso inherit access to files? In this example I think direct inheritence is ok enough but not always without end-user consequences. There's still a lot of paving to do on the road to sandboxing and this comment is probably not the best place for that :) Thanks for the input though. It may very well be useful in due time!

Wrt. Android permissions, their model is designed, in my opinion, to discard them from any responsibility (the user was warned and 'protected' by Android) whilst allowing the Android malware/adware ecosystem to thrive. It is very very symptomatic that they do not allow users to revoke a permission. I have no such plans and users will always have the last word. Besides, I really really want a model where users have to trust the developers of Linux, systemd, etc., their desktop environment and noone else. I refuse to be told by an app developer what permissions they 'need', or by a packager who maintains hundreds of pieces of software and might be fooled by said app developer. I think we owe it to ourselves in the FOSS community not to create a heavy-duty machinery just for costemics, but for actual security improvements. For most apps it should be obvious when they need a permission, and if it's not obvious at install time it'll always be more or equally obvious in the context where the permission is actually 'needed' by the app.

AnonC, if you're seriously interested in app sandboxing (and if you're willing to help design or develop them) I suggest you get in touch. I'm working on it, Lennart Poettering is working on it and a lot of GNOME people are as well. I don't know whether we'll manage to all work together and reach our respective goals, or even if we're trying to design the same mechanism, but there's always room for chatting and proposing in our world!

Cheers.

IMHO identicons are hard to remember, users will probably only remember colors ("it was blue, but had some red in it"). I think set of images shipped with distro + ability to use your own is the best idea. I'm trying of ways to reuse this image for some security stuff. (So that user remembers it, but associates it with security and won't install and play a game of "how fast can you find your image". :) ) For example if we wanted to slow down user and make him think, we could display 5 images in auth dialog and make him pick his "secret" image. I also thought about using user account's picture for this purpose, but what if it's the same pic as on Facebook/G+/etc. account?

And I think that "CCTV" webcam dialog is better than the other one, as it really vividly shows the user bad things that can happen if evil app gets that privilege. :) I think all graphical representations should be like this.

@user

This image is not to be considered as an authentication credential, because it is displayed. Opening up the UNIX account could be achieved with just the password in a SSH connection, which is what a remote attacker would use. An attacker with the ability to execute local code (exploit in malicious file, or malicious app/plugin) doesn't need to authenticate. And finally a physical adversary (who does not have the skills to dump your disk/ram or to just boot on a LiveCD as root -- especially for people who still don't encrypt their disks) may very well observe which image you click on and then the only point left of that image being displayed is eating up the user's time.

If you wanna use images for authentication, 3 rounds of 9 images barely provide you the entropy of a weak/very weak password. It also needs to be forbidden to reuse the profile picture for system-authentication. Users would probably feel very trusty if they see their profile pictures. "It knows it's me, since it's putting my face -- I can probably type my password". Somehow they all expect phishing attacks to be extremely crude, whilst they are not always...

Hi Steve!

The Exaile + Ex Falso interaction is actually quite simple and not unique to dynamic languages. The way I implemented it was to simply import Ex Falso's Python module and then hook up some of their internals with Exaile's. In that sense it's no different to e.g. how old browsers (pre-WebRTC) suddenly allows access to the user's webcam if the Flash plugin is installed. Is it Firefox or Flash that wants access to my webam? A crazier example, which does not even involve shared library files, is one executable calling functions directly from another executable using a custom dlopen(). Now that I think about it, even one process launching another (or one process instructing another through IPC) could be quite as confusing to handle.

Yet another interesting discussion is regarding something like browser-based "applications". Can we—at the system level—segment permissions required by each "application", regardless of the fact that they are all running in the same process and in the same window? Using the earlier webcam example, can the system allow webcam access for one website but not another, or are we restricted to making the browser / Flash handle the access control with their own authorization dialogs etc?

As an aside, have you thought of how your research applies to the session-locking mechanism (i.e. whatever is going to replace XScreenSaver in Wayland), which is affected by many of the same issues?

@Steve

Of course! I meant auth as in authorisation - app asks for permission and if we really wanted to make user stop and think a bit (but do we need to? Is it good UX-wise?), we could make him pick image instead of clicking "Allow".

@user

@sjohannes pleased to see you here

You're perfectly right about what you say! One could use Exaile's identity and permissions to run ExFalso, however it might be that one should rather understand that if the user wants ExFalso, the user might want ExFalso's privileges too. Typicall ExFalso has a legitimate reason to write to files whilst Exaile doesn't! If I wanted to record some video sequence with my camera in an app normally devoted to e.g., website-making, then it'd be great to have a trusted interaction method to convey that meaning and distinguish from the case where the website-making app is trying to spy on me and report to its editor about e.g., my coding-time snacking habits!

More generally, we must come up with a way to express software dependencies whenever they involve changes of privileges, and with a way for the user to consent to such dependencies or to provide us for evidence of consent while naturally interacting with the system. This has less to do with the existence of permissions themselves than with the sandboxes that will be plugged on top of them in the future. It's no trivial task, I'm afraid.