The GEM vs DMA-buf part makes me wonder - is it worth to try to use memfd mechanism proposed by kdbus authors? |
Hi Jack, I can't really comment on that, but memfd is for CPU-access so it can only replace SHM-buffer sharing. GEM and DMA-buf are about doing GPU-buffer sharing which is an entirely different beast. |
Is it possible to implement an application like X Neural Switcher which needs to intercept input/output with the security restrictions? |
Hi Boris, Even without the restrictions, I don't think it can be done right now with Wayland. This is a very good question though and you should ask Peter Hutterer, AKA the input guy :D As for you worrying about the default policy blocking that, you are damn right as it will block it. However, with the proper file in /etc/wayland/authorized_clients.d/, it will run fine without asking you anything. I guess this what you expect and you'll be fine with it. |
/etc/wayland/users.d/ would be hard to maintain on a big networked enviroment where users are stored on LDAP and their homes are on NFS. |
@Davide: You are right although big organizations aren't likely to grant additional rights to a user. I guess we'll need to discuss with RH engineers about that, I'm sure they'll have a perfect solution! Thanks for the feedback though! |
Here's a weird idea. What about re-using existing concepts in a novel way? We know that the compositor sends to my graphics device. What if the compositor had a virtual device, but the security checks were only valid against this virtual device. So, if I want to let an application record my screen, I go to my display configuration and I have to configure mirroring into this device, as though I had added another monitor to my server. Distributions might choose to enable this by default, but users could turn it off. You could even have a privacy toggle that temporarily flipped it on and off. With clever enough implementation, it could be done in a zero-copy type fashion that wouldn't take extra CPU or memory. Another type of re-use would be re-using the compositor. We have a concept of displays and compositor nesting - the system compositor nests the session compositor. What if an application like VNC, or X Neural Switcher, had to register as a sub-compositor of the session compositor? In this model, I would have to explicitly direct my application to use the alternate display. Only applications running inside this compositor could have their input and outputs intercepted, because the owning compositor has control of that. In some ways this doesn't solve your issue, because the signaling problem is still there. How does the user know that the virtual mirror display hasn't been turned on? How does the user know that his application is, for sure, running in a compositor that is or is not intercepting his input and output? OTOH, if it's only enabled at runtime and not persisted, then you have the I/O security to know that the user has explicitly clicked a button or pressed a key or otherwise made the configuration change that would allow this. And finally, if you're worried about total security, there's also the issue of 1.) a virtual graphics driver, 2.) scripted calls to the wayland equivalent of xrandr to turn it on, and then 3.) the secret, unknowing copying of output from it from bypassing the wayland layer completely. Yeah, it's advanced and really complicated, but any local buffer overflow could provide the opportunity to drop binaries and/or run commands. |
This is why once privileges have been granted, the user needs to have a way to keep track of who has access to restricted interfaces. I read the paragraph beginning with this line and scratched my head for a bit. Is it fair to make the user responsible for this? Won't this just condition users to blindly click "Allow" for everything that asks it? Obviously, the underlying OS (compository, GEM, etc.) must ensure that an application can only read its own graphics buffers (in order to preserve confidentiality), unless the application is somehow "privileged." But we would want to avoid breaking the user experience by always asking "allow/deny" every time one application wants to read another's graphics buffers. One solution is to let screen-grabbing logic run in the (privileged) desktop environment, and let the desktop environment act as a trusted screen-grabbing service to be invoked by one or more non-privileged screen-grabbing clients. Unlike the compositor, the desktop environment (including the UI toolkits and window manager) is aware of the individual widgets in each application. This lets the application (or user) can mark widgets as "private," which the DE interprets as "invisible to any clients of the screen-grabbing service." For example, Firefox could mark its non-visible tab widgets as "private" by default, so that when I go to use a screenshot application, the DE's screen-grabbing logic ensures that the text in each tab except for the visible one appears scrambled (or blanked). This could all happen automatically, and at arbitrary granularity. Most of the time, per-widget visibility policies would be set to sane defaults by the application developers and by the packagers. A user could override them in a per-window context (i.e. lasting over that window's lifetime), per-session context (i.e. setting a default for all windows in the session), a visibility context (i.e. setting a default for all windows in a virtual desktop, or on a specific monitor), and a per-application context (i.e. affecting all application-owned windows). Finer-grained policies governing individual widgets could be exposed by either the application or the UI toolkit configuration. |
Hi Martin, The Wayland EGL code in mesa has supported buffer sharing by fd passing (DMA-BUF) for a long time. For a while, there was still an gem flink operation in the path (the insecure step that assigns a globally accesible name to a GEM buffer), but in mesa 10.0 that's gone. So as of mesa 10.0, Wayland also satisfies your confidentiality and integrity conditions. As for launching clients securely, we've always used the mechanism you describe: the compositor forks a client and passes the connection fd in the process environment. See http://cgit.freedesktop.org/wayland/weston/tree/desktop-shell/shell.c#n4914 for an example and you can find the weston_client_launch() helper here: http://cgit.freedesktop.org/wayland/weston/tree/src/compositor.c#n272. The only difference is that we pass the fd number in the environment variable WAYLAND_SOCKET, not as a command line parameter. |
@jude Perhaps this could be solved in the following manner: Normal distro security policy should be to always allow screengrabs by default, but security-minded ones, such as in a government office, could set it to always deny. Output confidentiality is not something that all normal users need, but is a must-have for others (gvmt). |
@epiphany: As you said, this sounds complicated, both for the developers and for the users. It can also become very confusing for users. As for supporting the "X Neural Switcher" case, I talked to Peter Huterrer and he said he doesn't work on this just yet. He told me the guys at openismus are working on the input method and will be able to answer your concerns better. Here is their projects page: http://www.openismus.com/projects/ @jude: User Experience researchers have long said that if asked often, a user will always answer yes and don't bother with the security (even if the message is clear and not UAC-style). What we propose is something that should allow the compositor to know which decision should be made most of the time, thus minimizing the cases where the user has to prove its intent. That being said, you propose a way to hide the content of applications who decide they should be private. The problem is that this feature needs to be content-driven, even vi could contain your list of passwords or other stuff... This is an interesting idea nonetheless and something achieving the same result could be done by asking every application for the buffer they want to display to the screenshot grabber (instead of using the same buffer as the one displayed on the screen). Users will complain that they want the exact same content and developers will say it will be problematic for video grabbers because of the dual-rendering needed. Finally, compositors do not have any idea of the content of applications, widgets are rendered by them. If we want to gourven a widget from the compositor, we'll need the secure widgets UDAC proposes! @riking: Steve (from this website) and I knew people would argue that it the security policy of X is just fine. We believe it isn't and we are preparing a survey where we hope to gather enough data to know what security properties users expect. I'm pretty sure they expect a lot of them if not all of them. |
This is a problem more generic than Wayland compositors. Say I have a game on my PC and there is the shared highscore database, but only the the trusted binary (full path and not running under some controlled environment) should be able to change the database score. I see a per-binary (full path) + per-user case and I see a per-binary (full path) shared database. What do you think about a daemon database managing the shared/secure data per-user and global? All the hard-to-secure code would be driven way to one daemon that solve the issue for several applications. |
I think it would be nice to have a network backend to manage the fine grained security out of the user workstation. The idea is to be able to have a server controlling the access to the privileges, which can also be accessed through a ldap backend for extra segregation and replication. Such a design could enforce security by using another entity to do all the validation work insulated of direct threat of bad bad naughty softwares launched on the client workstation, it could also be powered by another operating system than the client are running. It would be possible to remote manage the policy easilly, to ensure better integrity of the policy, monitor and log access and thus detect problems based on abnormal behaviors analysis (for instance, application trying to break too much security properties), and ultimatly, alerte the administrator. Of cause it's not something every wayland user will do at home, but if we want to appeal more enterprises, especially security aware ones, the fact wayland could be a integrated to the NOS is undeniably an asset. |
@Vinipsmaker: Not sure if you are trolling me or not :D Anyway, in case you are not and you are new to the topic (which is of course OK and I'm glad you got interested in it), what you want is called Mandatory Access Control and there are plenty of implementations. Most of them use the LSM hooks I discussed in this article and the most common ones are SELinux, AppArmor, Tomoyo and Gr-sec. Have a look at it ;) |
@mupuf:
I'm just kind of new to the topic (hell, I learnt the "formal" concepts of confidentiality, integrity and availability of input and output reading your article).
I knew about SELinux, but I don't see how a tagging mechanism can guarantee per-user (all I saw was tag objects, which can be files, sockets, ... and "attach" tags to executables). I still don't know how tagging can cover the same field (per-user+app view of some data), but even so, I can already see that such system is way less fragile (you directly tag objects and they cannot escape of the fragile of binaries under some path).
Thanks for all the mentions. I'll wrote it down and read research all of them. :) |
PS.: this comment system asks my email, but it doesn't warn me about future replies. kind of awkward. |
@Vinipsmaker: I do receive emails but I agree, either this comment system is buggy and I should fix it or gmail doesn't always deliver the emails. I added some band-aid before sending the article but I sometimes do not get emails. I'll check that during the week. Anyway, have fun when studying security ;) |
Vista introduced a MAC for graphical applications. If a privileged app attempts to show a standard user a gui windows will ask for administrator credentials before allowing them to interact with it. |
Just a minor nitpick: |