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?
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!
Stay on the Cutting Edge
Join the experts who read Tom's Hardware for the inside track on enthusiast PC tech news — and have for over 25 years. We'll send breaking news and in-depth reviews of CPUs, GPUs, AI, maker hardware and more straight to your inbox.
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
OpenBSD: An Operating System Designed For SecurityReply
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.
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
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
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.
Wow, it's a girl. Let's have an article about her, it'll draw the horny teenager crowd!Reply
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