JEP proposed to target JDK 17: 411: Deprecate the Security Manager for Removal

David Lloyd david.lloyd at redhat.com
Tue May 25 13:29:28 UTC 2021


On Mon, May 24, 2021 at 11:17 AM Sean Mullan <sean.mullan at oracle.com> wrote:

> Comments inline ...
>
> On 5/22/21 10:11 AM, David Lloyd wrote:
> > ...  In addition, the JEP proposes deprecation of the access
> > controller and policy classes which are the mechanism of stack-based
> access
> > checking, and finally unavoidably bumps against JAAS, which itself is a
> > very difficult and problematic API which also uses the same stack-based
> > access mechanism (and which we here at Red Hat have for the most part
> long
> > since abandoned).
>
> Has Red Hat mostly abandoned JAAS entirely or more specifically the
> stack-based JAAS authorization mechanism that depends on the Security
> Manager? I'm just curious why this proposal is important to you - is it
> on behalf of Red Hat or just your personal preferences?
>

Yes, we have mostly abandoned JAAS other than in a few specific cases where
it is baked into, say, a certain JDBC driver or Kerberos implementation or
something like that.  Our replacement mechanism relies on immutable
security identity carriers which are locked into lexical scopes to prevent
accidental identity or authorization leakage, but still relies on
`Principal` for identity and permissions for authorization.

I'm thinking on behalf of Red Hat customers, but really on behalf of *all*
users who currently rely on SecurityManager (or more specifically, on the
ability to restrict permissions for certain services).  In many cases, it
is a requirement for certain security certifications that certain customers
may require as a matter of course.  The idea here is to largely move the
cost burden of security from the JDK to the specific vendor(s) who wish to
provide that additional service, without making it substantially more
difficult than it is today to provide that service.


> > However, one other undeniably useful function of the security manager is
> to
> > authorize basic native operations *not* in the context of what code is
> > executing, but what person or principal is executing it.  In other words,
> > the use case of *trusted* code running on behalf of one of many
> potentially
> > untrusted users - probably the widest application of server-side Java in
> > existence today.  It cannot be argued that removing all of the above
> > security checks does not weaken security of such users, when they could
> > have a narrower authorization applied to them to limit the possibility of
> > impact of server exploitation.
>
> But I assume that in these cases, it is due to a vulnerability in some
> trusted code that the user exploited or a weakness in some higher level
> authorization mechanism that the user was able to subvert.
>

Right; a security manager is not proof against implementation error, nor is
simple rigor, ultimately.  But every layer of protection helps.


> In practice, I don't think the Security Manager can or should take the
> place of a user-based Authorization provider. It is too low-level and
> too difficult to use and deploy, for the reasons mentioned in the JEP.
> But I think you agree with a lot of that anyway.
>

Right, the mechanisms in place today are not really ideal for providing
these kinds of protections for reasons that I think have been
well-established.


> > ...as well as their dependent methods and security checks.  These checks
> > generally pertain to determining whether the application or its
> frameworks
> > are trusted to perform certain operations, but are far less useful for
> user
> > authorization, as far as I can determine.  I would probably even include
> > the system property access methods as well - though I saw Peter arguing
> > that those in particular were useful, I have my doubts, but that could
> > obviously be worked out.
>
> Right, and I think this becomes a slipperly slope and would result in
> long and endless debates about which permissions people think are
> important. What about RuntimePermission "exitVM.*"? That is typically
> not an issue for server applications, but if you include that, then one
> could say that is useful for sandboxing against untrusted code so why
> not RuntimePermission "createClassLoader", and all the other permissions?
>

I think exitVM is a bit of a unique case, and thus is probably not the best
example to support this argument.  It is completely possible to trust a
library (potentially one that may not be modified) but note that it does
call exit - and having a mechanism to block that isn't really about trust
or any other higher principle; it's simply a pragmatic way to make life
somewhat easier.  Also, in this case, the cost of this check is very small.


> > Essentially what I propose is only slightly departed from the current JEP
> > 411 proposal, by introducing the exception of retaining certain
> permission
> > checks and the security manager class itself.
> >
> > Please give this compromise some consideration. Thanks!
>
> I think if we are to consider this path (and that is something that
> would involve more discussion), it would be much cleaner to define a
> completely new API, say "ResourceManager" and make a clean break from
> the Security Manager. I think this idea can be explored more in later
> JDK releases to see if there is merit to this approach. I think it would
> be much harder, and confusing to keep the Security Manager around but
> for a much more limited functionality, and decide which permissions are
> ok, which are not, etc. We would have to define what is the "old" vs
> "new" Security Manager.
>

I can understand this point of view.  The fact that the Security Manager
*is* historical however does not invalidate its utility or its potential,
and (odd as it feels to be saying this) there are some nice elements to its
design.  Any new API that one might propose to perform this function would
have to make the same evaluations in terms of permission checks, and would
likely have the same general code shapes.  I think it would be more
palatable to "step down" the implementation as I described - after all, the
remaining parts can still be deprecated and removed later if it turns out
to be a bad idea.


> Let's move Java forward rather than keeping one foot in the past.
>

Look, nobody is more surprised than I am that I'm arguing against
completely removing this thing! :-)  But I don't think that keeping the
base API can fairly be characterized as keeping a foot in the past.  Some
of the APIs didn't age well - like ProtectionDomain, which is a bit awkward
(using URL, rather than say URI) or the old package-sealing or JAR-signing
mechanisms, for example.  That's where a lot of the complexity lies, and
AccessController is where a lot of the liability lies.  I think it's OK to
start aging these things out.  However, the basic Permission system may
have a few minor rough edges but it's basically a sound system that is
still in use by modern APIs.  And retaining strategically placed permission
checks seems like a great way to offer a more open end to security without
taking on the liabilities.

-- 
- DML • he/him


More information about the jdk-dev mailing list