XDC2012: Graphics stack security

Posted Sep 27, 2012 14:50 UTC (Thu) by Siosm (subscriber, #86882)
In reply to: XDC2012: Graphics stack security by dgm
Parent article: XDC2012: Graphics stack security

> Regarding Wayland security, security has to be possible, but not mandated.

If it's not enabled by default, nobody will use it because it won't get testing and bugs won't be fixed.

> By locking down applications we make them less useful.

Only a very limited set of applications has to be "locked down" in the Wayland/Weston case. Any "classic" application won't even notice the change.

> Think for instance what will happen if the Unix shell mandated integrity of input or confidentiality of output for all programs: pipes would be impossible.

This is hardly comparable. On a classic *nix system, you use different users to separate tasks which should not interact with each others. Communications channels between users (pipes...) must be explicitly created, most of the time by the most privileged user. Without MAC (Mandatory Access Control) there is no confinement between applications from the same user.

With GUI applications, everything runs under the same user, so we can not rely on user separation anymore. In the Wayland/Weston case, only explicit user controlled channels allow interactions between applications (drag&drop, copy&paste).

> Having insecure input and output, _in_addition_ to secure ones, is clearly desirable and good.

Again, people will naturally choose the easy way over the hard way.

In order to work, security has to be default built-in design feature which should make common operation easy, and control uncommon operations.

to post comments

XDC2012: Graphics stack security

Posted Sep 28, 2012 10:34 UTC (Fri) by dgm (subscriber, #49227) [Link] (4 responses)

> If it's not enabled by default, nobody will use it because it won't get testing and bugs won't be fixed.

Sorry for the harsh words, but this is the LAMEST possible argument you could make. If it was useful for someone people would use it. If it's not used it's because it's not useful, so we're all better without it.

This strategy did not work all that well for GNOME, please do not repeat this mistake again.

> Only a very limited set of applications has to be "locked down" in the Wayland/Weston case. Any "classic" application won't even notice the change.

Nope, you got it wrong. Take virtual keyboards, for instance. Currently they are not possible in Wayland because it has been decided that the compositor should not touch input in any way, applications receive it directly from the kernel. This decision effectively locks down _all_ applications, even those for which input integrity is of no use.

> With GUI applications, everything runs under the same user

This does not need to be this way.

> Without MAC (Mandatory Access Control) there is no confinement between applications from the same user.

And that is, the ability to pass information between applications, is what makes them useful. What we need is a mechanism to confine _selected_ applications.

> Again, people will naturally choose the easy way over the hard way.

True. Also, people chose what works over what does not.

XDC2012: Graphics stack security

Posted Sep 28, 2012 21:54 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

>Nope, you got it wrong. Take virtual keyboards, for instance. Currently they are not possible in Wayland because it has been decided that the compositor should not touch input in any way, applications receive it directly from the kernel. This decision effectively locks down _all_ applications, even those for which input integrity is of no use.

And that's good. You can implement a virtual keyboard right way, by writing a CUSE driver. This way every app in the system will be able to access it. Or you can extend the compositor to do this.

XDC2012: Graphics stack security

Posted Oct 1, 2012 4:08 UTC (Mon) by raven667 (subscriber, #5198) [Link] (1 responses)

>> If it's not enabled by default, nobody will use it because it won't get testing and bugs won't be fixed.
>Sorry for the harsh words, but this is the LAMEST possible argument you could make. If it was useful for someone people would use it. If it's not used it's because it's not useful, so we're all better without it.

It may be lame but it's true, non-default options don't get as much testing as default options, especially in volunteer-tested software, the less-used code paths are more likely to be buggy. Sure, some people will use non-default config options but their experience may be sub-par because of it.

In any event, reasonable security options should be enabled by default. Imagine that something like password hashing were a non-default feature. What would happen is that most people would never turn it on and have plenty of bad things happen as a result. After the second or third time the security design problem bites them maybe they'd turn on the more secure feature but then would find themselves locked out of their system or some other horrible fate after which they'd find out that nobody turns the security feature on because it doesn't work. So then they'd just accept the additional risk of doing things in a more risky way that is likely to have a bad outcome because that's just the way things work.

It seems that this kind of scenario has played out many times over the years, like MS Windows putting people in the Administrators group to get around the entire permissions checking system. The Windows issue with the Administrators group and all the trouble that has caused over the years seems to be exactly the kind of thing they are trying to avoid.

XDC2012: Graphics stack security

Posted Oct 1, 2012 4:20 UTC (Mon) by dlang (guest, #313) [Link]

there are security options that can be turned on because they don't break anything (i.e. hashed passwords) and security options that should not be turned on by default because they do break things (the examples in this case that break all soft keyboards, screenshot programs, etc)

many security people fall into the trap where they consider security the most important thing. In the real world it isn't. Security is a matter of risk, and you have to balance risk vs benefit.

XDC2012: Graphics stack security

Posted Oct 4, 2012 7:39 UTC (Thu) by farnz (subscriber, #17727) [Link]

Nope, you got it wrong. Take virtual keyboards, for instance. Currently they are not possible in Wayland because it has been decided that the compositor should not touch input in any way, applications receive it directly from the kernel. This decision effectively locks down _all_ applications, even those for which input integrity is of no use.

Have you a cite for that? My recollection, backed by the protocol spec is that the Wayland compositor is the only application that gets input directly from the kernel; everything else is notified of events by the compositor. This is essential if the compositor is to transform events in arbitrary fashion - how can a surface know where it is in kernel-global coordinates if the compositor is the only thing that knows about the arbitrary transform applied to it?