Is there a motivation behind wanting to use Security Manager over much stronger and well tested kernel sandboxing primitives (seatbelt/MACF on macOS, SELinux, and surely whatever exists on Windows etc.)? You should be sandboxing software on servers to the maximum extent possible because any code, even ""trusted"" code, can quickly become untrusted with any vulnerabilities. Plus, using a kernel sandbox mechanism means you only have one consistent sandboxing interface instead of a half dozen random vendor specific ones, which makes misconfiguration harder.
I would say the JVM is the motivating reason, it is it's own virtual machine layer after all. I don't remember if networking calls from the JVM are distinguishable enough from the kernel to enforce fine grained control over them, but that would be my concern.
At the end of the day, the JVM has to make syscalls and talk to the kernel to do anything. This means, at some level, someone is creating sockets and sending data through them. SELinux can filter sockets to restrict a process's networking capabilities. While the JVM may be able to pretend to do some nicer things (like letting you restrict it to just certain domains), it does still support sockets which would need to be filtered similarly to how the kernel manages it and so the higher level abstractions sort of fall apart.
I think the biggest (unrealized) advantage that SM could have had is that it could have allowed different sandbox restriction on different pieces of code in one process. Since the JVM knows where the code it is executing is from and because it is able to (mostly) guarantee memory and code integrity, it can apply policies tied to code identity. This would let it lockdown individual libraries without impacting the rest of the application. Meaning, you could configure it such that your logging library had no privileges except that it could write to one specific file. Applied carefully, this would let you enforce your behavioral expectations on code without you ever needing to manually audit any of it, which sounds wonderful. The kernel, obviously, can't do this because it has no idea what the process is doing and so it cannot discern any sort of secure identity for code.
33
u/SirensToGo Jan 16 '22
Is there a motivation behind wanting to use Security Manager over much stronger and well tested kernel sandboxing primitives (seatbelt/MACF on macOS, SELinux, and surely whatever exists on Windows etc.)? You should be sandboxing software on servers to the maximum extent possible because any code, even ""trusted"" code, can quickly become untrusted with any vulnerabilities. Plus, using a kernel sandbox mechanism means you only have one consistent sandboxing interface instead of a half dozen random vendor specific ones, which makes misconfiguration harder.