4 ms·
I don't have the inclination to write a long comment about this. But reading sections like this: >This state can then be verified whenever a process performs a
by catern 10y ago
I don't have the inclination to write a long comment about this. But reading sections like this:
>This state can then be verified whenever a process performs an action requiring a permissions check. For example, when a process requests that a file be opened, the kernel now calls out to the hypervisor. The hypervisor is then able to examine the process state and ensure that it remains consistent with its internal representation of process state.
Makes me very uneasy. You're making the hypervisor more complicated, duplicating the logic in the kernel, because you feel the kernel is insecure. The only argument for doing this, AFAIK, is that the hypervisor is still simpler overall, and therefore more secure. But when you start introducing these kind of complications, that argument becomes kind of farcical... Adding another layer on top of the kernel and duplicating your permissions checks in there, I do not think that will end well.
- mjg59 10y agoYou can take a look at the patch - there's very little additional complexity in either the kernel or the hypervisor. The kernel permission checks remain unmodified, with the hypervisor checks as a backup. The argument for this isn't that the hypervisor is simpler, it's that the hypervisor is running at a separate privilege level to the rest of the stack. The hardware enforces an additional level of separation. This just adds validation on the other side of that boundary. (Disclaimer: author of the code)
- pranavkpr 10y agoYup, completely agree with you.
- daveguy 10y agoBest disclaimer ever.
- xkxx 10y agoHey, author, thanks for commenting. AFAIR, you also are the guy who criticizes Ubuntu's policy regarding derivative works. Anyway, I have a question for you. If I understand rkt's architecture correctly, the hypervisor runs multiple Linux kernel instances, every kernel runs several processes. If somebody exploits one of those processes and creates a root-owned process, then rkt detects such an attempt and restarts the kernel. But what if the exploit doesn't create any root-owned processes? You can get rights equal to those of the superuser without getting uid=0.
- mjg59 10y agoIt also detects any bump in capabilities. Getting superuser level abilities without modifying either your uid or your capabilities would require modification of kernel code.
- xkxx 10y ago> would require modification of kernel code And it's impossible for an exploit to do because?.. EDIT: "?.." in this case means "please continue my sentence".
- mjg59 10y agoKernel code is mapped read only
- xkxx 10y agoThanks for taking time to answer my questions. > Kernel code is mapped read only What part of the system makes sure that read-only kernel code stays read-only? Is it hardware or the hypervisor? Another question. Is there any chance that you missed something and there's a way to get privilleged access without actually modifying your uid, bumping your capabilities or modifying kernel code?
- mjg59 10y agoThe hardware - it's an attribute on the page table. You could certainly monitor that from the hypervisor as well, although there'd be some performance overhead. You can avoid all of these protections if you can inject new code into an existing privileged process or SUID executable, which is how DirtyCOW worked. The blog points out that this class of vulnerability isn't covered.
- xkxx 10y ago> The hardware - it's an attribute on the page table. And the only way to make the page writable again is to clear the page first. Am I correct? > You can avoid all of these protections if you can inject new code into an existing privileged process or SUID executable, which is how DirtyCOW worked. It can happen if either one of these is true: 1) the existing privileged process or SUID executable is vulnerable; 2) the kernel is vulnerable. DirtyCOW is interesting because it's the case #2. The case #1 is not that interesting, because targeting vulnerable privileged executables is a known attack vector.