5 ms·

Am I wrong in thinking that this is sort of like worrying about leaving the kettle-on while you're falling from a skyscraper? Sure, if you have a rogue applica

Am I wrong in thinking that this is sort of like worrying about leaving the kettle-on while you're falling from a skyscraper? Sure, if you have a rogue application on your computer, it can access the GUI of a program whose security is critical (e.g: a password manager), but even if all the GUI were isolated, you've still got a rogue program on your comp. All the security posts I've ever read have pretty much told me that once you're running a malicious program, then it's game over, your system is owned by your adversary and the only good way to move on is to wipe the drives, and start fresh. Why then worry about GUI isolation? If the GUI is isolated, a rogue program can presumably uninstall your secure GUI server and replace it with another! This blog mentions Qubes, which is cool and does mitigate the rogue program from what I understand, but anything short of isolating whole applications from each other at the hypervisor-level, is fussing about the wrong thing IMHO. Then again, I'm not a security professional, so what I've said is likely all wrong...

kalmi10 11y ago
Note that this piece was written by Rutkowska, the mother of Qubes OS in 2011.
drdaeman 11y ago
Well, I think it's very useful to counter that core "once you ran something malicious you're screwed" issue and have a way to run any untrusted software in a solid isolation, i.e. without fear it could compromise the whole system. Is there anything wrong about this?
- guard-of-terra 11y ago
  Javascript in browser does just that.
  - drdaeman 11y ago
    It does (although not without the issues, we have CORS, NoScript and firejail for a reason), but that's completely irrelevant to X11 problems mentioned in the article.
    - guard-of-terra 11y ago
      You have one way to run software in solid isolation, but it is not enough for you? No, X11 won't provide it for you, but browser will.
nickpsecurity 11y ago
It depends on the nature of the attack and the attacker. Most attacks are rehashes of what black hats made available that are easy to counter with patches, a good configuration, or even sandboxing. Targeted attacks hit specific weaknesses in applications. Aside from detection, you can try to use tech to remove classes of weakness or (simpler) attempt to isolate each program giving it just enough privileges to do the job. Programs accepting input from untrusted, isolated programs check that input for sanity/security. They raise an alarm if something is wrong. QubesOS is in that category. It's technically called a Multiple Single Levels (MSL) of security system. The isolation tries to keep problems in each VM.
zby 11y ago
Do you disable Java Script in your browser? Or maybe you only go to websites that you are sure about?
the8472 11y ago
X-isolation obviously wouldn't be the only isolation mechanism you'd use to run untrusted code. For other things you would use namespaces, seccomp and chroot. But X is the one thing that can't be done well by those because granting access to the unix socket that's needed by X means leaving the barn door wide-open.
api 11y ago
You are correct. Linux is a single user OS. Any rogue program can almost certainly escalate privileges using any number of strategies across a vast and complex surface area. It's been almost two decades since unix systems were routinely used in true multi tenancy situations with untrusted tenants. Since then nobody has paid any attention to this aspect of security.
dandelion_lover 11y ago
>> once you're running a malicious program, then it's game over I don't think it's that simple, all or nothing. Security is not a boolean. Consider defense in depth [0]. edit: Security is just a price to hack you. You can increase it by adding additional problems to an adversary. [0] https://en.wikipedia.org/wiki/Defense_in_depth_%28computing%29 https://en.wikipedia.org/wiki/Defense_in_depth_%28computing%...
conceit 11y ago
>you've still got a rogue program on your comp. That's the default case, because any program that has bugs and takes foreign data has to be considered untrusted. >All the security posts I've ever read have pretty much told me that once you're running a malicious program, then it's game over Well, isn't that because of gaping holes like in the X11 design besides any bugs? > anything short of isolating whole applications from each other at the hypervisor-level, is fussing about the wrong thing IMHO. Unless it has bugs, too. (And if it doesn't because it is simple enough, it will evolve to send mail and eventually get bugs, or the applications are just monoliths that can't be well hypervised)
Houshalter 11y ago
That's not really true. Tremendous effort has gone into making sandboxed programs. Otherwise any website that has JavaScript could take over your computer. The browser is basically a functioning sandboxed operating system. There's no reason that can't be true of actual OSes. All programs could be sandboxed by default. But they just were designed under the assumption that all app makers would be good and no one would ever download and run malicious programs. Yeah, right.
- ffk 11y ago
  One such feature is the use of seccomp, which removes all but 4 system calls: read, write, sigreturn and exit This is used by many browsers and apps to reduce the impact of security flaws and untrusted code (such as js from a website).
marcosdumay 11y ago
When you ssh -X into a machine and run a compromised program, this will stop this program from taking over your computer. It is one part of the puzzle of sandboxing software on a machine. But is certainly not the entire solution.
superuser2 11y ago
This is true of Linux, non-app-store Windows apps, and non-ap-store OSX apps. But with the App Store walled garden craze came a much better idea: let's end this "all programs having full run of the filesystem" nonsense and sandbox them, such that it is very hard for a user to compromise his entire machine by installing one bad program. iOS has always been this way, App Store OSX apps are increasingly this way (already has filesystem sandboxing), I believe Windows App Store is pushing this direction, Android has this to an extent, etc.

kalmi10 11y ago

Note that this piece was written by Rutkowska, the mother of Qubes OS in 2011.

drdaeman 11y ago

Well, I think it's very useful to counter that core "once you ran something malicious you're screwed" issue and have a way to run any untrusted software in a solid isolation, i.e. without fear it could compromise the whole system. Is there anything wrong about this?

guard-of-terra 11y ago
Javascript in browser does just that.
- drdaeman 11y ago
  It does (although not without the issues, we have CORS, NoScript and firejail for a reason), but that's completely irrelevant to X11 problems mentioned in the article.
  - guard-of-terra 11y ago
    You have one way to run software in solid isolation, but it is not enough for you? No, X11 won't provide it for you, but browser will.

nickpsecurity 11y ago

It depends on the nature of the attack and the attacker. Most attacks are rehashes of what black hats made available that are easy to counter with patches, a good configuration, or even sandboxing. Targeted attacks hit specific weaknesses in applications. Aside from detection, you can try to use tech to remove classes of weakness or (simpler) attempt to isolate each program giving it just enough privileges to do the job. Programs accepting input from untrusted, isolated programs check that input for sanity/security. They raise an alarm if something is wrong. QubesOS is in that category. It's technically called a Multiple Single Levels (MSL) of security system. The isolation tries to keep problems in each VM.

zby 11y ago

Do you disable Java Script in your browser? Or maybe you only go to websites that you are sure about?

the8472 11y ago

X-isolation obviously wouldn't be the only isolation mechanism you'd use to run untrusted code. For other things you would use namespaces, seccomp and chroot. But X is the one thing that can't be done well by those because granting access to the unix socket that's needed by X means leaving the barn door wide-open.

api 11y ago

You are correct. Linux is a single user OS. Any rogue program can almost certainly escalate privileges using any number of strategies across a vast and complex surface area. It's been almost two decades since unix systems were routinely used in true multi tenancy situations with untrusted tenants. Since then nobody has paid any attention to this aspect of security.

dandelion_lover 11y ago

>> once you're running a malicious program, then it's game over I don't think it's that simple, all or nothing. Security is not a boolean. Consider defense in depth [0]. edit: Security is just a price to hack you. You can increase it by adding additional problems to an adversary. [0] https://en.wikipedia.org/wiki/Defense_in_depth_%28computing%29 https://en.wikipedia.org/wiki/Defense_in_depth_%28computing%...

conceit 11y ago

>you've still got a rogue program on your comp. That's the default case, because any program that has bugs and takes foreign data has to be considered untrusted. >All the security posts I've ever read have pretty much told me that once you're running a malicious program, then it's game over Well, isn't that because of gaping holes like in the X11 design besides any bugs? > anything short of isolating whole applications from each other at the hypervisor-level, is fussing about the wrong thing IMHO. Unless it has bugs, too. (And if it doesn't because it is simple enough, it will evolve to send mail and eventually get bugs, or the applications are just monoliths that can't be well hypervised)

Houshalter 11y ago

That's not really true. Tremendous effort has gone into making sandboxed programs. Otherwise any website that has JavaScript could take over your computer. The browser is basically a functioning sandboxed operating system. There's no reason that can't be true of actual OSes. All programs could be sandboxed by default. But they just were designed under the assumption that all app makers would be good and no one would ever download and run malicious programs. Yeah, right.

ffk 11y ago
One such feature is the use of seccomp, which removes all but 4 system calls: read, write, sigreturn and exit This is used by many browsers and apps to reduce the impact of security flaws and untrusted code (such as js from a website).

marcosdumay 11y ago

When you ssh -X into a machine and run a compromised program, this will stop this program from taking over your computer. It is one part of the puzzle of sandboxing software on a machine. But is certainly not the entire solution.

superuser2 11y ago

This is true of Linux, non-app-store Windows apps, and non-ap-store OSX apps. But with the App Store walled garden craze came a much better idea: let's end this "all programs having full run of the filesystem" nonsense and sandbox them, such that it is very hard for a user to compromise his entire machine by installing one bad program. iOS has always been this way, App Store OSX apps are increasingly this way (already has filesystem sandboxing), I believe Windows App Store is pushing this direction, Android has this to an extent, etc.