Qubes OS: An Operating System Designed For Security
Approaches To System Security
Alan: Hi Joanna, thanks again for taking the time to chat with us.
Joanna: You're welcome.
Alan: Since I know you’re busy, I’ll just throw in a link to our previous interview (Exclusive Interview: Going Three Levels Beyond Kernel Rootkits), in which you talked about the risks beyond the rootkit, and ask that our readers skim through it first.
I really want to get to talking about Qubes OS, though.
For the benefit of our audience, I want to review the three approaches to system security. We have security by obscurity with things like memory randomization, obfuscating code, and system administrators mandating complex passwords. This acts as a first line of defense—if the bad guys can’t find your house, they can’t break in. It’s a deterrent that encourages the bad guys to look for an easier target. But it doesn’t work when they really want your data.
Then we have security by correctness, where software developers try to write bug-free code so that there are no vulnerabilities. Every time software gets patched, it’s a little bit more correct. But as we see every second Tuesday of the month, even the resources that Microsoft has are insufficient to come up with a perfectly correct OS. Modern software is so big and complex that it’s almost impossible to validate code to be perfect.
Finally, we have security by isolation, which takes a somewhat pessimistic (though more realistic) view that, at some point, the bad guys will break through whatever security measures you have, and so the focus should be stopping the bad guys from getting access to the rest of the system. Fair summary?
Stay On the Cutting Edge: Get the Tom's Hardware Newsletter
Get Tom's Hardware's best news and in-depth reviews, straight to your inbox.
Joanna: Ha! I wish more interviewers were so well-prepared. :)
I would perhaps add to this one more category: reactive security, which in practice comes down to: patches and signatures (for IDS and AV). Of course, this approach is the least effective, as we all well know.
Alan: The problem with security by isolation is that popular implementations like Safari’s or Chrome’s sandboxing or Internet Explorer’s Protected Mode are great in concept, but less secure in real life. Is developing perfect isolation just as difficult as security by correctness?
Joanna: Well, one still needs security by correctness when implementing isolation (sandboxing). The difference is that this is only needed for the code that enforces the isolation, not for all of the code.
If we can design a system where the isolation-enforcing code is very small, than there is a clear win—we have much less code to write correctly.
On the other hand, if one tries to build a sandbox on top of a huge, buggy, monolithic system, which exposes numerous complex APIs to applications, then the amount of code that must be written correctly is not that small, and the potential gain is much less obvious.
As a side note, I find it funny how the word "sandbox" became such a buzzword. Since the early days of multitasking OSes, the system was supposed to provide isolation between processes and users (address space isolation, access control to file system objects, etc.).
Thus, we can say that on any multitasking OS, for decades, every process has always been "sandboxed." It's just that, first, the sandboxing was designed for server applications and not for desktop applications (where all processes usually run as the same user), and second, OS kernels turned out to be buggy, and not so effective at enforcing this isolation.
Today's sandboxing technologies attempt to address the first problem in that they try to be more suited for desktop applications.
This might, for example, require splitting a browser into several processes: one for rendering, another for user interface handling, and so on. This is all good, but the second problem mentioned above still remains unsolved. Can we rely on a big, fat, and buggy kernel that has hundreds of drivers inside, networking stacks, and so forth to enforce strong isolation?
People who regularly release kernel exploits for popular OSes (Linux being no exception) seem to be yelling: NO!
US govt says Cisco gear often targeted in China's Salt Typhoon attacks on 8 telecommunications providers — issues Cisco-specific advice to patch networks to fend off attacks
USB-C cable CT scan reveals sinister active electronics — O.MG pen testing cable contains a hidden antenna and another die embedded in the microcontroller
-
iam2thecrowe i wont use it, because i dont really understand half of what is written in the article, they lost me at Bare Metal Hypervisor, but what the hell is with the seemingly random picture of the woman with the scarfe around her neck?Reply -
LORD_ORION iam2thecrowei wont use it, because i dont really understand half of what is written in the article, they lost me at Bare Metal Hypervisor, but what the hell is with the seemingly random picture of the woman with the scarfe around her neck?Reply
The "bare metal hypervisor" is Xen. In a nutshell, it runs directly on the hardware of the server machine, and that is all it does (you install Xen, and it consumes the whole drive) You then install your operating systems virtually ontop of Xen. To access your operating system, you login to it from another machine using special Xen client software.
As Xen is what runs the amazon elastic cloud, there is need for high security OSes like Qubes for enterprise business applications. -
FloKid Life always finds a way. I just wonder if you put a function for a USB and a function for an ethernet port in the same code, won't that start two kernels even if they are isolated and basically give you access to both in the same code? I might not be getting something, but I could see the same program having a hard time accessing all of the other kernels, since they are not in the same process. Could be good I guess, but I can see sorta a way around that if you have other malicious software already running hidden.Reply -
3-R4Z0R So this is essentially the same thing as Minix, only that it's been reinventing Minix again (just like about 20 other projects during the last 15 years that have never come as far as EU funded Minix which is even partially POSIX compatible)?Reply -
nevertell So what they are doing is sandboxing stuff into partitions using Xen ? WHY?Reply
I am more interested how are they making the transition between the domains, because if they're using IOMMU to have a discrete videocard available to the domains, how are they sharing it between the domains ?
Tom's, you could make an article about virtualizing Windows 7 on top of xen with a normal Ubuntu install in dom0 and have a discreet videocard for windows 7 and use the integrated one for ubuntu/linux, like a sandy bridge igpu and some nvidia/radeon. If you prove that the transition between the domains is fast and easy, this would be AWESOME for regular linux users, as I hate to reboot to play some games. But that way, I could just switch between the domains, at any given time. I mean, RAM is cheap.
-
killerclick Wow, it's a girl. Let's have an article about her, it'll draw the horny teenager crowd!Reply -
amigafan Lol there would be more comments on this particular article but veterans know they'd quickly get decimated with thumbs downs ;)Reply
I won't even bother with mentioning "kitchen" in any context :D