XDC2012: Graphics stack security
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
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.
Posted Sep 28, 2012 10:34 UTC (Fri)
by dgm (subscriber, #49227)
[Link] (4 responses)
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.
Posted Sep 28, 2012 21:54 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
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.
Posted Oct 1, 2012 4:08 UTC (Mon)
by raven667 (subscriber, #5198)
[Link] (1 responses)
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.
Posted Oct 1, 2012 4:20 UTC (Mon)
by dlang (guest, #313)
[Link]
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.
Posted Oct 4, 2012 7:39 UTC (Thu)
by farnz (subscriber, #17727)
[Link]
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?
XDC2012: Graphics stack security
XDC2012: Graphics stack security
XDC2012: Graphics stack security
>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.
XDC2012: Graphics stack security
XDC2012: Graphics stack security
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.