->最小権限の原則の必要性を議論したい
議論 www.reddit.com
>The discipline of working with least privilege need a boost though.Much of the work on strong encapsulation in the module system works toward that end.
→ (賛成)「モジュール機構が最終的に最小権限の実現手段になれば」
No your module visibility is not a new Security feature, we also support OSGi, which has used ClassLoader's to manage visibility for much longer. People using newer releases of Java will suffer greater consequences if and when perimeter security breaches occur. Instead of creating a whole new API for Java Serialization filters, you could have just created a Permission, and my policy generating tool would have calculated the white lists at test time prior to deployment. Out of curiosity, are there any tools for whitelisting Java Serialization?
→(反対)「OSGi使って実装してるけど今のところ最小権限の代用ならないよね」
Now, while it is true that any mechanism that can provide some measure of security is removed could be said to harm security by some degree, that is not what's at issue. The issue isn't whether to keep the Security Manager in addition to any other security measure, but whether to continue investing in the Security Manager at the expense of other measures.
I believe that strengthening the JDK's security across the board, having "principle of least privilege" restrictions that are in place by default through strong encapsulation, and improving JFR's monitoring so that it could detect a great many attacks would be much more effective.
（賛成)「SecurityManagerの代わりに、strong encapsulationとJFRの検知機構を改良していけば」
he basic dispute here seems to be between people who believe the SecurityManager is theoretically sound and useful, thus could be improved to work better in practice, and those who see it as a lost cause or that everything can be solved with module boundaries. I don't think anyone disagrees that today the SecurityManager is not used much, and is much harder to use than it should be. The question is whether that's due to fundamentally unfixable problems or just general neglect.
Without the SecurityManager Java doesn't have any way to restrict the privilege of code, whether that be untrusted plugins or code that might be exploitable like deserialization libraries (as gadgets may be intra-module). The bytecode rewriting approach you put together was a good start but it seemed to show pretty clearly why JVM/core libs support for this is a good thing to have - there were immediately lots of corner cases people pointed out that were missed, some of them quite subtle. The existing access checks, problematic though they are, do at least enumerate the places where access checks may be needed, and the JVM is the source of all linking decisions. Trying to modify that behaviour at the bytecode level is a poor substitute.
→
The debate here is between people who think that because the number of attacks the Security Manager has actually blocked in the wild is very small and its cost is large and it should therefore be removed to make room for more effective security, and those who think it's brilliant and should therefore be retained, even though it is expensive and adds little value to the ecosystem.
メンテナンスコストの割に役にやってないという部分を話しないと平行線になりそう。
ElasticsearchがSecurity Manager使っている。
Apache River also makes heavy use of SecurityManager.
「”誰もSecurity Manager使っていない"て言ってるけど、セキュリティのため使っているところ色々あるよね」(サーバーサイドで）
Those people always says "no one runs with a Security Manager" but, there are a lot of systems using it for keep platform stable and secure. They just ignore them with some reason I cannot understand.
(反対)「SecurityManager APIは長い間使われてきて堅牢となった。だけど、OpenJDKの新しいSecurity APIはまだ定義されていないし（省略）」
SecurityManager API's and permission checks are hardened with the test of time, with many eyes carfully going through code, looking for vulnerabilities. OpenJDK's new experimental vaporwear Security API's haven't even been defined yet and aren't even part of the spec.
「OSが提供する最小権限では粒度が荒いよね」
Using an OS process to limit permissions of the JVM isn't fine grained enough. What I present really is least privilege principles, regardless of what anyone with vested interests in removing SecurityManager might say.
level 2
