Hacker News Reader

Comment by exabrial | Hacker News Reader

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.

When IBM developed Websphere for the 1996 Atlanta Olympics, they wanted a mainframe, but you know, web stuff. The model was doomed from the start, as they designed the JVM to run as a process.

Sun attempted tried to get deeper kernel support for the JVM with Solaris, but ultimately just ended up developing the precursor to LXC Containers called Solaris Zones.

What we have today with containers is pretty awesome but it was definitely a bumpy road to figure it all out.

View on HN

.NET Core doesn't support the .NET version of security manager (CAS), and the is actually a JEP for deprecating the security manager for removal.

The JAAS idea was quite good, however it was too complex for most developers to implement properly.

I see a big failure for .NET and Java not having been a JIT/AOT stack since the beginning, and now we are going through their reboots while trying to keep the existing ecosystems to fall apart in the process.

I believe it's JEP 411 [1], good ridance, there is nothing worst than a false sense of security.

[1] https://openjdk.java.net/jeps/411

What's the link between WebSphere and the Olympic games?

> 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.

The comment from @pron in the sibling thread explains the difference. Android applications, in general, don't share process.

That'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.

The 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).

Yes, 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.

Reply on news.ycombinator.com