3 ms·
> In process sandboxing was definitely one of the worst ideas attempted in the early days of Java. None of my jobs in the last 10 years have ran with the securi
by jfrunyon 5y ago
> In process sandboxing was definitely one of the worst ideas attempted in the early days of Java. None of my jobs in the last 10 years have ran with the security manager enabled, as it's just useless. I'm suspicious of any modern technology attempting to do the same thing, as it's just hard to get right.
I think Android has done a very good job with their permissions, which seem quite similar to me. Am I missing something?
Yes, properly limiting permissions is difficult, and there can be bugs, but that's true regardless of what layer the security controls are applied at.
- gene91 5y agoThe comment from @pron in the sibling thread explains the difference. Android applications, in general, don't share process.
- dfox 5y agoThe Android API gives me the feeling that the original idea was to do in-process sandboxing in mostly same way as it is done in Java and run the whole thing as one giant JVM instance and only later it was changed to the process-for-app model (which probably was not that much of breaking change because lot of things that cross the process boundary had to be serializable/parcelable already because of how android activity lifecycle handles memory pressure).
- jfrunyon 5y agoThat's true, but largely irrelevant. > Yes, properly limiting permissions is difficult, and there can be bugs, but that's true regardless of what layer the security controls are applied at.
- pjmlp 5y agoYes, the fact that each application is usually a process, and a mix of Linux kernel features are used for sandboxing, namely LinuxSE, seccomp and eBPF. Also despite being based on Linux kernel, since Project Treble Android has doubled down on its Binder mechanism for IPC across drivers, kernel and activities with multiple processes, which in the end makes it look like microkernel based architecture.