[ art / civ / cult / cyb / diy / drg / feels / layer / lit / λ / q / r / sci / sec / tech / w / zzz ] archive provided by lainchan.jp

lainchan archive - /sec/ - 122



File: 1492620001479.png (11.56 KB, 225x225, images.jpeg)

No.122

So we just had a discussion on "Simple questions thread" that I think deserves it's only thread.

The discussion is about virtualization vs sandboxing. I'll post the comments bellow and you can contribute to it.

  No.123

>the thread starts here
why are you using whonix?
It's much simpler to just point all your traffic to localhost and allow TorDNS. You'll not leak nothing. All these things about Whonix, and Qubes and Tails seems kinda idiot to me (except some good bits, like randomized mac address by default). Virtualization doesn't mean more security. It mean "security done the bloat way"

  No.124

>>123
>But, I'm curious: why are you using whonix?
I use it just to experiment, but it is really more secure. Unless an attacker manage to get out of the VM or attacks the gateway your IP is safe, someone with root privileges can bypass a firewall.

>All these things about Whonix, and Qubes and Tails seems kinda idiot to me

Why do you think so? There are great advantages in some of those.

>Virtualization doesn't mean more security. It mean "security done the bloat way".

Virtualization really means that it is more difficult for someone to get full control over your computer.

  No.125

>>124
Virtualization is the bad way to do security.
Let's get the Matryoshka doll analogy: you want something to be safe. Will you add more dolls to cover the layer 0 (that's where your secret stuff is) or do you want only one doll, but with much stronger security?
You can still say that you want more dolls, but you're not considering one factor: the materials cost.
When you put too many dolls there's too much effort to do these dolls and to maintain their security and it turns to be simple to get an exploit when you have so many "materials" (code).
The right way to do it is to fortify the layer 0 with better materials, not more materials (in this analogy it would be the equivalent to use sandboxes), not to put more, entire, dolls.

You can also check this thread:
http://marc.info/?l=openbsd-misc&m=119318909016582&w=2

Together with the above said, the x86 virtualization is not a real virtualization. Different from other architectures like SPARC64 that had a special chip for virtualization, x86 runs virtualization on microcode. Since microcode is absolutely close source, you don't know what the fuarrrk is going on.

>There are great advantages in some of those.


I can see only one advantage these, and it's on Tails: the non persistence of changes.
But, you can do that with other systems too, especially the runs that use ramdisk.

  No.126

>All these things about Whonix, and Qubes and Tails seems kinda idiot to me

Yes, it's kinda idiotic to put the system/applications in a virtual machine, rather than actually harden them.

In fact, we do have underlying groundwork, such as the famed PaX/Grsecurity kernel, and recent plagiarism adoption by KSPP is a great improvement of security; userspace/compiler hardening is essential also, we already have NX, stack-protector-strong, RELRO, D_FORTIFY_SOURCE, PIC/PIE. A sandbox/virtual machine can't provide these protections, we need more of them, and we need to adopt them to systems. And systemic audits are always needed.

But please understand, even with these hardening, sandboxing/virtual machine is a requirement if higher degree of security is needed, in order to restrict the damage of an exploit if it has happened. Instead of a single point of defense, we need defense in depth.

Also, a PDF reader code execution can do everything a user can. Given how our operating systems, applications are designed, there is really no better way to achieve privilege separation and reasonable level of security, especially on the desktop system.

Yes, if the applications and operating systems adopt a different approach to security, it will be the elegant the completely solution, but we still need FireFox to browser the web and use a Unix-like system in a foreseeable future, that is what virtualization is coming for.

This xkcd comic #1200 elaborates this problem well.

Also, an attacker can do a lot of things, as everyone knows, it can implant a rootkit, but what less known is, they can also insert a permanent hardware (firmware-level) malware that almost nobody can detected because it starts before any OS kernels or even bootloaders. And all of these can be done remotely, by software exploits alone. So once you have been hacked, booting from Tails CD could still gives you a compromised system. There is no effectively countermeasures, at least on x86, besides virtualization.

You really need to check the "x86 considered harmful" article by a main Qube dev.



ps. link to a image and to the pdf cited:
https://www.lainchan.org/sec/src/1492492344800-0.png
https://www.lainchan.org/sec/src/1492492344800-1.pdf

  No.127

>>126
I don't know... I understand your argument, but I think reinforce my previous one.

>restrict the damage of an exploit


That's why we need privsep and sandboxing. I do not disagree with the usage of privsep mechanisms, but I do disagree with the estimated 'security' people think virtualization will bring.
If you need to restric the damage, don't throw thousands of LOC above the main system. That's why there is capsicum and pledge.

>Instead of a single point of defense, we need defense in depth.


My point is that, it's not depth. It's an illusion. If you put many lines of code, that can hardly be audited, above everything else, how is this going to help? Using a simples sandbox would be better, or, use better software that is simple enough to spot all the high risk bugs and that has privsep by default.

>a PDF reader code execution can do everything a user can


That's a issue for the pdf software, isn't it? Just use something better, like mupdf without the JS module and without the networking module, or, for the most paranoid, convert pdf to images then open it.

>there is really no better way to achieve privilege separation and reasonable level of security, especially on the desktop system


http://man.openbsd.org/pledge.2

>we still need FireFox to browse


I, personally, don't. I use Links most of the time (on ion3 wm for tabs). But, I understand what you're trying to say...

>And all of these can be done remotely


Well, if you find some proof please send it on misc@openbsd.org
It is possible to reflash your firmware with malicious code, but not remotely, unless you find some really nasty vulnerability.
Also, firmware malware is not the worst. The worst is hardware trojans, that is the manipulation of the microarchtecture itself to defeat some functionality of the processor. That's way worst scenario than firmware or system vulnerability, since no one can verify that (there is some academic tests, but not really).

>You really need to check the "x86 considered harmful" article by a main Qube dev.


I'll check that, thanks.


I can see myself support Qubes in the future if they go with seL4 VM, then that would be some interesting soykaf (even though it would still be susceptible to microcode attacks).

  No.128

>>127
Capsicum is like kicking dead whales down the beach however, Pledge is the only thing that is being implemented on large scale.
There also is Seccomp for Linux but it isn't being used on large scale few applications use seccomp where Pledge is being used in the entire base already.
I think only OpenBSD does virtualization right with vmm/vmd with Pledge?
What i miss on OpenBSD is a RBAC like grsecurity has.
Anyway i don't think Xen is the right way but OpenBSD can indeed be improved here and there.
Just a reminder that most applications aren't built with security in mind so there is very little priv seperation, the only ones actually doing it are OpenBSD applications ( OpenSSH, OpenSMTP, ect )

  No.131

>>125
Sounds nice in an ideal world where everyone can run the Muen seperation kernel, but in the real world we have linux which is a big security vulnerability, and windows which is an even bigger one.

>>127
>big = insecure

many short, easily-understood programs are actually very vulnerable, and many giant projects are airtight. What matters is how well those are designed and maintained, not how tiny they are.

I encourage everyone here to look into genode, which makes sandboxing and application seperation a core part of the OS architecture. I firmly believe it's the future of OS design.