SELinux has xorg hooks [1] to isolate the gui, actually... yes that means with SELinux you can control which window can talk to which, what clipboard can be used where, by what window, etc.
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.
I particularly disagree with her assertion that Xen is a more trustworthy place for security over the "big, bloated linux kernel". I would argue that the (perhaps smaller) Xen code has seen far less security scrutiny than the kernel and has a far less pronounced culture of security.
Linux doesn't have a good culture of security. Local root bugs are dime a dozen. Security fixes in the kernel are not flagged as such. There's no systematic effort to stop the most common types of security bug (memory bugs in some driver ioctl handler). Linus doesn't have much patience for or interest in security improvements - look at http://article.gmane.org/gmane.linux.kernel/706950 - Etc etc.
Before submitting, I debated whether to put a disclaimer line in - "not that the kernel has the worlds best security record", but I thought - nah nobody's going to use this as an opportunity to jump in & grind their "kernel security" axe. What a fool am I.
I however think the relative silence around Xen security is far more of a worry. That was my point.
I agree with the concern and appreciate the solution that Qubes offers.
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]
BTW, Windows is the only one mainstream OS I'm aware of, that actually attempts to implement some form of GUI-level isolation, starting from Windows Vista.
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.)
Yes. Here's a Windows keystroke logger (with source code) that uses GetAsyncKeyState. I wrote this years ago to show an IT auditor that a restricted user could run a keystroke logger (he was adamant that was not possible). It works on Windows XP to Windows 8.
Oh man! I only wrote one program ever that could be used for malicious intent if so desired, and that was a GetAsyncKeyState()-based keylogger. Simple to write and so cool. The toughest part was figuring out how to register itself as a windows service and give it a good name so most people would ignore it. I ended up making a separate executable for that.
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).
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.
The very first comment below the article (correctly) contradicts the author's claims about SELINUX sandbox. The author acknowledges the comment, and criticizes the SELINUX implementation, but does not dispute the fact that SELINUX sandbox ("sandbox -X xterm" in RHEL/CentOS/Fedora/SL) does in fact defeat the keystroke logger attack described in the article.
I would be nice if the article was amended to acknowledge the fact that a SELinux sandbox actually avoids "the problem".
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.
The yum install xorg-x11-apps bit is so you can use the xinput tool as a demonstration of the problem. Fedora doesn't have it by default apparently so you need to install it.
A malicious app could just directly use the X protocol, no need to call this app, so unfortunately no additional privileges are needed.
Apparently you don't need to execute it with elevated privileges so you can build it (or your own variant) statically on a different machine for all you care.
"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."
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.
In the 1990s I worked at an investment bank, all the developers had X terminals (these were workstations that just ran X servers, they did not have any other local compute or storage resources). I discovered one day that I could run a program and direct the display to any X terminal in the network. There were some screensaver-type programs that would make everything on your screen a mirror image, or appear to melt down and run off the bottom of the screen. It made for some fun pranks.
i've been saying for awhile now (to anyone bored enough to listen) that qubes style isolation is the only safe idea on offer these days. i just wish qubes were usable.
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.
Doesn't djb espouse a similar viewpoint wrt sandboxing? Not to say she doesn't have any original ideas for how to achieve it, but it's hardly a novel concept.
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.
Oh come on, sexist? Did you read her exchanges in the comments? She's just another Torvalds, with respective to her attitude and people skills. Why shouldn't we call her on it, if we criticize Linus?
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.
You would be wrong. Torvalds gets some regular hate-machine action here every couple of months. Someone finds a frustrated mailing list message of his and posts it out of context, and half of the resulting comments are about how Torvalds really shouldn't be a project lead with an attitude like that, or how he's damaging open source, or all sorts of pronouncements on his behaviour.
I think the kind of people who are bothered about Linus' tone are likely to be bothered about similar things in other people. For my part I've never found Linus particularly offensive and I'm equally puzzled by people who disagree with Joanna's style too. Perhaps some people are just too easily offended.
Can someone (who is more familiar than me on this topic) comment on whether this is a by-product of Xorg running with root privileges.
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 ?
Well, if you count Android as mainstream OS then it too has GUI isolation. One app can't receive key events when another has focus, nor can it inject events into other applications.
That proof-of-concept relied on a custom protocol extension which, as the author pointed out, was not meant to be merged in Wayland/Weston. In any case the extension required application to ask the compositor to be notified of the pointer position even when not "owning" it and the compositor can flatly refuse it to non-privileged clients according to any policy it wants, which is quite different from the current X11 situation.
Interesting that this comes up again with Ubuntu Trusty continuing to retain Xorg. Is anyone familiar enough with Mir and Wayland to comment on how those packages approach this kind of thing?
Both fix it by making snooping and spoofing unavailable by default. An application only has access to its own windows, inasmuch processes are properly isolated in other aspects as well. Typically they aren't, e.g. very few distros have any "single user level" safeguards for ~/.bashrc. Qubes solves that problem as well.
Does it actually matter? For the average desktop, everything of monetary value will be under the main user account. Which is generally also the account used to touch the internet.
I think it does matter. Defence is relevant at almost every level of software. If a window manager can make smart design choices to make it non-trivial to implement bad software for the interfaces it serves, it's an obvious choice IMO.
Glad to see this reposted(although it being this specific article is of no particular value, there are other articles on this which don't have such shameless plugs).
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.
Blogging about a problem and giving your solution is not a shameless plug. What would you prefer, an article which describes a bunch of security problems and doesn't tell you how they can be resolved?
For a lot of end user systems it doesn't really matter if cross-user protection boundaries exist or not because there is only one user on the system. It is the lack of sub-user protection boundaries that is a big concern.
I agree if I launch app A and I launch app B its ok if they can see what the other is doing. But what if some nasty process launches an app. Of course, viruses (etc) are very rare on Linux.
OK so I get the problem with a program running as a given user being able to grab all of that user's key strokes.
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.
On my last OS reinstall, I tested out Qubes but was put off by the lack of AppVM graphics card support (I do game development) and lack of bluetooth (wireless mouse + headphones) support. I understand these are key security holes and are absent for a reason, but in my view being able to enable these would have been an acceptable compromise between usability and security - the reality is that my personal security situation is not so critical that I am going to go without these modern conveniences, but I would still like to make it as difficult as possible for attackers otherwise.
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)
This question is asked in the comments of the article as well, and receives an incredibly unprofessional answer:
> (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...
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...