JEP411: Missing use-case: Monitoring / restricting libraries

[Peter Firmstone]

Although JGDMS is a different type of system, this is one of the 
functions of SecurityManager in our system also.

We have methods equivalent to Subject.doAs, which instead of injecting 
the privileges of the user into all ProtectionDomain's, instead prepends 
a ProtectionDomain that represents the user's Subject onto the call 
stack.  When used in this way, it changes policy file permission 
grant's, it actually simplifies them, because you can grant 
AllPermission to trusted code, if you want to, and then limit user 
permissions and it will restrict only the user, however this doesn't 
fully explain why we do this.

https://pfirmstone.github.io/JGDMS/jgdms-platform/apidocs/net/jini/security/Security.html#doAs-javax.security.auth.Subject-java.security.PrivilegedAction- 


To explain this, requires briefly revisiting the 8 fallacy's of 
distributed computing, that is, item 6, there is only one administrator.

So for your single JVM server, or many instances of JVM's operating 
independently, yes, there is only one administrator, but this is not the 
case for a distributed system.

The reason we prepend a ProtectionDomain representing the user, is that 
there are ProtectionDomain's on the stack that represent Services other 
administrators are responsible for, it just happens to be proxy "code" 
that implements an interface, or interfaces, used for method calls 
between the two systems.  These proxy's are assigned a ClassLoader based 
on the Server's security constraints, the server Endpoint address (by 
the proxy's InvocationHandler implementation) and the codebase annotation.

So it's not really about the code, it's about the Service's identity and 
keeping the identities of different services separated from each other 
(even those using the same proxy code, with different server identity, 
eg for lookup services from different entities) and users, to avoid 
granting those Services all the users permissions while also allowing 
the user to authenticate with the service and also run as a logged in 
subject in threads on the remote node as well.

As previously explained, the permission's required for Service proxy's 
are negotiated dynamically at runtime, between the two parties.  We 
don't grant all the permissions the user has to the remote service 
provider, only those that have been negotiated, when a secure connection 
was first established, so the user allows the service provider to 
utilise some of the users permissions. The service provider cannot 
currently obtain more permission than the user has.

In versions of Java, without a security manager, the third party service 
provider will have AllPermission, and the user will have restricted 
permissions (if we still have some form of user Permission based access 
control).   So basically we might as well remove all access control 
completely and say that all users and all code is completely trusted, 
the system will be much more user friendly and easier to use, but 
legally that can present problems.

It does appear that a side effect of JEP 411, perhaps even an unintended 
consequence, will be to limit Java to trusted networks with one 
administrator.  It is most certainly appears to be a single JVM focused 
change, or a system controlled by one administrator.

Newer versions of Java will of course be less secure without access 
controls and unsuitable for use in a distributed system that involves 
more than one administrator.

In a way, it's ironic, IPv4 limited us to local networks, but now it 
looks like later versions of Java will now be the limiting factor.

I realize less utilized platform features like access controls aren't 
the concern of OpenJDK developers, but it doesn't appear to be doing any 
harm talking about them, at least so the consequences of the decision 
can be better understood.   I realize this is probably a business and 
marketing based decision.  I guess Java has more of an enterprise 
history, and it's giving that up to become leaner and more developer 
friendly (less things to learn or understand).

Cheers,

Peter.

On 17/05/2021 12:11 pm, David Black wrote:
> Hi Ron
>
> On Thu, 13 May 2021 at 20:22, Ron Pressler <ron.pressler at oracle.com> wrote:
>>
>>
>>> On 13 May 2021, at 03:11, David Black <dblack at atlassian.com> wrote:
>>>
>>>
>>> This seems somewhat more useful than 1 & 2 but imho it would be better to be able to perform checks/grant access on a call stack basis.
>> This is an important point we’re trying to get across. The very reason the Security Manager was made this
>> way is because it does *seem* better; certainly it is much more flexible. However, twenty five years of
>> experience have shown us that *in practice* this is not the case, certainly not when you look at the
>> ecosystem as a whole. It is hard to get right, which results in people not using the mechanism (which
>> significantly reduces its utility and the value in maintaining it), or worse, use it and think it gets
>> the job done, but actually use it incorrectly, providing the illusion of security without actual security.
> Agreed, but if you don't have this level of introspection/detail how
> do you propose to, at least partially, mitigating bug classes such as
> SSRF?
>
>>> Atlassian currently makes use of a security manager to prevent access to cloud metadata services that do not have an amazon sdk related class on the call stack. This helps to mitigate the impact of SSRF in applications running in a cloud environment (https://github.com/asecurityteam/ssrf-protection-example-manas-security-manager).
>>
>> We’re talking about a situation where *all* the classes running in your application are trusted,
>> i.e. assumed to not be malicious, and that an accidental vulnerability might exist in any one of them.
>> Can you explain why you believe this mechanism, that treats different classes differently is the best
>> way to improve security?
> Because it allows for restrictions to be placed upon "trusted"[0]
> classes so as to offer some mitigation against classes of bugs such as
> SSRF. You can also use a security manager to monitor for potential
> policy implementation issues & make adjustments. Specifically for
> SSRF, if you want to mitigate the issue you need to ensure that
> network connections being made respect proxy settings but also allow
> support for certain code paths bypassing proxy settings to access
> potentially sensitive network locations (e.g. cloud metadata
> resources) this can result in mistakes in configuration occurring and
> or finding libraries/classes that ignore proxy configuration. You may
> be thinking "oh but surely no library/class would have proxy
> problems?" well that answer is "yes they can and do". For example,
> https://bugs.openjdk.java.net/browse/JDK-8161016[1] was fixed in java
> 9 but has not yet been fixed in java 8[2]. In a similar fashion,
> OkHttp before version 3.5.0 could also fallback back to a direct
> connection[3]. So having a "belt and braces", prox(y|ies) and a
> security manager, approach is valuable.
>
>
> [0] "Trusted" classes are not immune to security issues
> [1] https://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/3dc9d5deab5d
> [2]https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/0056610eefad/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#l1180
> &  https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/master/jdk/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#L1180
> [3] https://square.github.io/okhttp/changelog_3x/#version-350