On Fri, Jan 10, 2014 at 12:13 PM, Martin Peres <[email protected]> wrote:
> Le 10/01/2014 16:44, Maarten Baert a écrit : > > On 10/01/14 14:56, Martin Peres wrote: >> >>> Please provide a detailed explanation for that and tell me how likely it >>> is to ever end up upstream. >>> >> If by 'upstream' you mean the kernel: I don't think anything new is >> needed, actually. Create a separate directory in /run/user/1000 for each >> application, use cgroups to restrict applications to their own folder >> (assuming that's possible, I didn't check it). >> > > And who would manage the sandboxes? Systemd won't be able to because it is > user applications. > systemd and logind both support user-spawned applications. In fact, one of the goals for the 3.12 cycle of GNOME is to work on systemd user sessions. > >> Until such sandboxing mechanism exists, what are we supposed to do then? >>> >> Only install and run applications we trust, and hope that our decisions >> are correct. Sadly that's the best strategy we have right now. >> > > I guess we'll need to educate users if we go this way. > > >> That's a fair goal, indeed. That means you want to leave the >>> authentication out of the protocol as much as possible so as you can plug >>> whatever decision-making system you would want. That's kind of LSM for user >>> applications. >>> >> I hadn't heard of LSM actually, but I think it's exactly what we should >> do. >> > > LSM just defines hooks, not the decision engine. > > >> I am interested in this and also think this is the future. In the mean >>> time, we should define a way that doesn't require any such system. >>> >> Or we create 'Wayland Security Modules' and provide a default module, >> which can then be replaced later if needed. >> > > That makes perfect sense and it was something we have been wondering since > 2012 :) > > > >> This conflicts just like SELinux and DAC conflict. Ever heard of DAC >>> override? We would just need the same system to be able to bypass the >>> current authentication scheme if using a later system. Is that satisfying? >>> >> Only if this can be done without changing every single client >> application. Let's say we go ahead and implement the system you proposed. >> This essentially forces all clients to launch themselves through the >> compositor, and register global bindings, and pass serials from those >> bindings in order to take a screenshot. That's already a huge nuisance for >> application developers, but let's ignore that. Now sandboxing appears, and >> all these old requirements make no sense with the new security model, in >> fact it makes things much harder because now the application, in its >> sandbox, will try to launch something through the compositor, outside that >> sandbox. The compositor now has to figure out how this sandboxing system >> works and put the newly launched application back in the same sandbox. Now >> the application tries to create a global binding, but are sandboxed >> applications even allowed to do that? >> >> There's a very real risk that requirements that make sense today will >> actually make things far worse in the future. >> >> It could take a decade. LD_PRELOAD would be much faster to get rid of in >>> the mean time. ' >>> >> There are valid use cases. Some debugging tools depend on it. OpenGL >> recording in my app depends on it. Even Steam depends on it for their >> 'community integration' system. It won't be removed any time soon ... >> > > Yes, but those apps who really need it should be compiled with it. Almost > all the other apps do not need this, especially not the ones we need to > trust. Who cares about the confidentiality of games ;) > > As for OpenGL recording, you won't need that anymore, will you? > >> >> The reason I think it is important to avoid applications from not using >>> the video feed directly is because of the notification needed for the user. >>> If he runs the application then tries to quit it then he will wrongly >>> assume he is out of the danger zone. >>> >>> If we mandate the application to start recording straight away, then the >>> user could check if the notification (most likely a red record icon in the >>> systray) is gone. >>> If the application didn't really quit and starts recording later on, the >>> user may not notice that the record notification appears. >>> >> Then the notification should be more obvious! If the user doesn't notice >> that it appears, then he may also fail to notice that it /doesn't >> disappear/ when he closes the application. Even more so because human >> vision is very sensitive to changes but not very sensitive to things that >> stay the same. >> >> >> We already have a notification system that's universally accepted: >> libnotify. Just show a notification whenever that systray icon appears or >> disappears. >> > > What if you missed it? libnotify can be added to make it more obvious, but > a sticky icon should always be visible on screen. > > >> However, now that I think of it, the notification could indicate an >>> application has the rights to do the recording. This way, we don't waste >>> ressources and the user still is able to tell if he is out of the danger >>> zone. >>> In this case, you should be able to start and stop the video recording. >>> >> Sounds much better :). >> >> Just tell your users they need to select your application as the screen >>> recorder and press the right hotkey to run it. No need for 2 applications >>> to communicate. >>> >> That's only doable now that you've dropped the requirement to start the >> recording right when the application is launched ;). I still don't like >> that the user now needs to remember another hotkey, it would be much >> simpler if the user could just start the application using his favourite >> launcher. If there is already a clear warning icon in the system tray (and >> probably a nice big notification as well), then why is this restriction >> still needed? >> > > Because a clear notification just never exists. People won't see the > change unless they look for it. The notification is just here to expose the > state of the system. > > What you want is what Sebastian described: The compositor should ask the > user if he agrees in the case where an app didn't get launched by the > compositor. In this message, it should be doable to remind the user he can > get around that message by setting the recording app to "the one he wants" > and then press "combinaison of key". > > And there won't be transferring gigabytes of data because the goal here >>> is to design an interface that doesn't use the CPU at all for screen >>> recording. Weston already has an example of that. Of course, the CPU should >>> be able to access the buffers from the GPU to do sw encoding, but that >>> should be fallback, not the normal path. >>> >> AFAIK there is no hardware encoder that comes anywhere close to the >> quality/bitrate ratio that x264 provides. I'm not dealing with a noisy >> 15fps 640x480 webcam, I'm dealing with 30fps 1080p video and often higher. >> A decent encoder is not a luxury but a requirement for live streaming at >> that quality. Hardware encoding is currently only feasible for recording to >> a file (that will hopefully be re-encoded later with a better encoder). So >> for me, hardware encoding is a minor feature that some gamers will like >> (because it leaves more CPU power for the game itself), but it can't >> replace software encoders yet. >> > > Agreed, sw encoders should still work (I said so in the very sentence you > quote). > >> >> Fair point. We don't have a system like that right now though. >>> >> I think the compositor will need one anyway at some point. Just let the >> compositor keep track of security settings in a root-owned file specific to >> that user. The file doesn't need to be /owned/ by the user just because it >> applies to that user :). >> > > Agreed. > > >> Yeah, but this is your app warning, not the operating system. I don't >>> want apps to do anything like that in the users' back. >>> >> How does that make a difference? If you trust that the application is >> responsible enough to do screen recording, then why wouldn't it be >> responsible enough to show that warning message? >> > > Because I foresee how they are going to be used. The user will never give > consent or even understand the security implication. Sure, the app has to > access the snapshots but let's lower the risks by requiring the user's > input ourselves. > > The difference is that there will be 3/4 wayland compositors while there > will be tens of screenshot apps. The screenshot apps will mostly be > un-maintained and people will add features to fit their needs and screw > their security (while we don't have a good sandboxing system). > > >> I want a protocol that is as secure as possible without sandboxing, yeah. >>> >> And I believe that the best thing we will ever be able to achieve without >> sandboxing is a false sense of security. >> > > Output confidentiality is something that is doable without sandboxing. > Only screenshot apps are a threat to that and I want that threat to be > limited by requiring a clear user action (either press the right hotkey or > via a pop up) before allowing screenshots for that app. > > >> My goal here is to restrict how much we need to trust "privileged" >>> applications. Sandboxing is just another (very effective) way of doing so. >>> >> So you're saying that you're okay with the risk that any application can >> read all your files, but not with the risk that they could take >> screenshots? I really don't understand that. >> > > I am not, this is the most critical problem on our distros today but it is > un-related to wayland, so let's not talk about it. > > >> Anyway, I keep telling we all mostly agree. The thing you don't agree >>> with is requiring a direct user input before giving the privileges. In the >>> future, the sandboxing technique could override that if needed. In the >>> meantime, I want it. >>> >> I suppose I can live with the limitation that my application can't be >> launched from the menu like all the other ones, for now at least. But I'm >> 100% sure that I will get complaints about it, and I expect that some users >> will disable the restriction completely to get around that. >> > > Well, the solution to that is to force the compositor to display a pop up > warning if the app was launched without it and the compositor should never > allow the user to say "Never ask me again". > >> >> As I said in the security presentation a friend of mine and I gave at >>> XDC2012, full screen apps grabbing all keys are an availability hazard too. >>> >> Easy to fix, the compositor can simply add a special key that makes the >> window normal again (and removes its ability to go fullscreen for some >> time). I'm more worried about the potential social engineering attacks. >> >> Actually, any access to OpenGL allows denial of service attacks, because >> GPUs are not pre-emptive (it never stops a task before it's done). This is >> also a big issue with WebGL. GL_ARB_robustness tries to mitigate this >> somewhat but it's really just a band-aid. But in practice, it seems that >> attackers aren't very interested in denial of service attacks, because it >> isn't actually being abused. >> >> >> _______________________________________________ >> wayland-devel mailing list >> [email protected] >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel >> > > _______________________________________________ > wayland-devel mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > -- Jasper
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
