The Linux Security Circus: On GUI isolation
theinvisiblethings.blogspot.fr
theinvisiblethings.blogspot.fr
not that it makes the xorg code better in any way, but, when you're going to say the world is ignorant and you know it all, at least get your stuff right.
Thats why people "hate" you as you describe in this post. Having an aggressive style doesn't make you more accurate. It just makes you annoying.
[1] http://www.nsa.gov/research/_files/selinux/papers/xorg07-pap...
It doesn't matter if you're right, wrong, or even interesting as long as you get the page views. Blech.
I agree, though, that the style is overly aggressive.
I however think the relative silence around Xen security is far more of a worry. That was my point.
It might be worth pointing out that some of the "hippies" also became concerned with this and implemented their own partial solution within the X framework decades ago -- the "secure keyboard" feature. You can see it in action: run an xterm, Ctrl-Left Click in the window, and choose "Secure Keyboard" from the menu. Now all X11 keyboard events are sent exclusively to that xterm, not to any other X application (even if the other application has focus). Caution: for these purposes the window manager is also an "application", so you won't even be able to Alt-Tab to switch applications while the secure keyboard mode is active!
The X11 developers assumed that you would use the Secure Keyboard feature while typing important passwords. There's a pretty elaborate discussion of this in the man page for xterm(1).
There, the threat that they're most focused on is remote display access from applications on other hosts, rather than malicious software potentially running on the local host. For example, the authors of xterm fear that you'll be using machines foo and bar in the same computer lab, and run "xhost foo" on bar, and then an attacker will rsh into foo and log in to their account there and then run "DISPLAY=bar:0 keyboard_sniffer" from their account on foo, whereupon the X server on bar will conclude that the remote client request from foo is perfectly legitimate because you told it to accept all X11 connections originating from foo.
Of course the secure keyboard feature only partially mitigates one aspect of this threat, while Qubes offers a much more thoroughgoing and useful mitigation to a larger range of things. (I might also mention ptrace, where recent Linux distributions have activated a kernel policy which forbids, by default, having a non-root process start to ptrace another running process that isn't its child. I believe this was in response to malware grabbing private keys from programs like ssh-agent via the ptrace interface. Oops. It does also mean that you can't strace -p or gdb attach something that's already running, unless you become root and change the policy.)
In general, the idea of protecting against software that's running locally as the same user is something of a novelty on most desktop OSes.
"The workings of mux, a windowed-terminal handler, that can run differently classified sessions in different windows."
[google search tip for historians/computer archeologists who don't want to find SE-Linux when searching for Unix history: enter "before 1/1/{years ago} as a custom time range]
Is GetAsyncKeyState still available in Windows Vista? I'm guessing it is, and processes can still read each others' keystrokes without problem. The MSDN documentation doesn't mention it being deprecated. http://msdn.microsoft.com/en-us/library/windows/desktop/ms64...
(By the way this article is from 2011. It would be interesting to read an update.)
That would be the same as running it as root, so in that case it would make sense that you can listen to get every keypress. If not... then yep Windows Vista is as much a 'security circus' as anything else.
Anyway, I got curious to see how my coding style had evolved since I was a kid so I dug it up for all to see: https://gist.github.com/aktau/11057438 (I was young, be gentle).
The article is becoming somewhat obsolete now with all the new windows/apple store apps though. (I m not talking about their store aspect)
I'm being confused with the "you will likely need to install it first: yum install xorg-x11-apps"; which means you need extra privileges before implementing the attack "as normal user!".
I guess the problem is not local access but a malicious app perhaps, but then it doesn't matter too much anyway because there are other ways of compromising the system.
A malicious app could just directly use the X protocol, no need to call this app, so unfortunately no additional privileges are needed.
Well, that's the idea - protect a user from malicious apps running within their security context. Qubes does this by running apps within their own virtual machines.
Genuinely curious.
i'm fairly sure that 10 years from now people are going to be citing joanna rutkowska articles with regularity. her flatfooted denial that security is possible without isolation is the only sane perspective.
the point is that starting from full isolation and straining to get things to talk to each other in the hope of achieving productivity makes sense. starting from full interactivity and straining to isolate but just when it's necessary "for security" is a battle we will all eventually lose, and we should know it already.
i'm not saying the concept is novel, i'm saying that it's the only viable option for the systems of today. related to that, i think the qubes approach will be adopted eventually (and that articles of hers, specifically, that i've read will likely come into fashion, despite the--dare i say it--borderline sexist reaction many on hn seem to have to "her tone").
regarding outright original thought, i'm sure both she and he are guilty of it. probably you and i as well; it's easier than a lot of people think. the world is large and complex, and really most of the "oh my god i can't believe [person] thought of [amazing idea]!" really ought to be marveling at the fact that [person] implemented [amazing idea] as a practical tool.
sure, we rehash over and over in our thought, but the world of ideas is so specialized that given even a few months of serious study, novelty is not particularly impressive.
She may be a brilliant researcher, but being aggressive and insulting toward others will only hinder her attempts to redefine the security landscape.
"given that kernels are your research project, i expected that you'd already tested whatever you're talking about on wayland and contacted its developers about security holes,"
and he replied curtly, i don't think anyone on hacker news would be "calling him out." the idea that her tone is "too aggressive" is highly suspect. it is not unusual to express ideas as if you believe them, nor to conduct yourself as if your blog posts needn't be written in the tone of My-First-Job-Interview or Visiting-My-Conservative-Grandmother-In-The-Hospital.
The systemd-logind work on Fedora [1] is attempting to run Xorg without root rights (and Wayland/Weston[2] in the future) and I'm wondering if that is a much more effective fix than all this sandboxing ?
[1] https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights
[2] https://plus.google.com/+DavidHerrmann/posts/ggK1tStCvJH
EDIT: longer discussion on Reddit - http://www.reddit.com/r/linux/comments/1viqpt/x_server_runni...
[1]: http://www.desktopsummit.org/sites/www.desktopsummit.org/fil...
This article has some useful information on how Wayland addresses the security concerns expressed in this thread: http://mupuf.org/blog/2014/02/19/wayland-compositors-why-and...
We really need some hard boundaries set between non-interactive and interactive requests to open files.
Sensible ones too - not "ask about every file", but maybe "grant process access to this folder in my documents folder, without recursive access".
Even better would be "fire this backup utility first, then grant access".
We now have Wayland well on its way to replacing X(I'd say within two to three years, some users won't ever know they're running Wayland), and from what I can tell, it will offer fairly good isolation for input.
Another important step is graphics drivers being cleaned up to improve isolation between graphical clients. For the time being, though, I can create a GL context and not draw anything, but still see parts of the framebuffer in my context, which I find giggle-worthy.
I think the basic problem here is that graphics systems are hard enough to make work at all, let alone make secure. I will probably not trust a system this complex to protect input or content for a long time, if ever.
I hadn't heard of Qubes, looks interesting.
But why try to stop something running as root from grabbing users keystrokes? If someone has root on your box it is pretty much game over for any security anyway. Anything that pretends that it isn't is actively bad since it will give you a false sense of security.
So to mitigate this simply have multiple profiles. One for work, one for banking etc and one with sudo access - and don't su into the sudo access profile just Ctrl-Alt-F1 when needed.
http://theinvisiblethings.blogspot.fr/2014/01/shattering-myt...
I find the concept behind Qubes fascinating. I only wish that it was more stable or that it supported native isolation mechanisms like FreeBSD jails.
Surely Qubes even with these security holes would be better than vanilla Linux? (This was roundly shot down as a proposition on the Qubes mailing list)
[0] http://wayland.freedesktop.org/
[1] https://security.stackexchange.com/questions/3589/passive-an...
> (commenter) Instructive article. But what about Wayland? Wayland is claimed to replace X soon. Major distros are already working on its integration. Are the authors aware of it or does it have the same design flaws?
> (author) @phocean: good question about Wayland, why don't you check for yourself? ;)
> (commenter) So I will when I have some free time. But as it is your research topic, I expected you had already done that or even contacted the developers to inform them. As it is still under heavy development, I guess it is a good timing to implement good stuff and for expert like you to advise them.
> (author) @phocean: Don't kid me, kid! What I did here was not a "research" (you might want to check some real research we did at ITL on our website). That was just a Saturday morning blog post with an aim to save some lost souls, like yours... And I really don't have time to go and test all the software in the development that is out there. I do have real job, that among other things includes doing real research...
This is why ssh X forwarding disabled by default.