[External] : Authorization Layer post JEP 411

[Peter Firmstone]

Ok, thanks Ron,

I think we are confirming that Java, post version 17, will not meet the 
security needs our software.  It's time I accepted that and moved on.

Thanks for your time.

Have you seen my latest article on foojay?   Feel free to comment and 
let me know what you think.

https://foojay.io/today/jep-411-what-it-means-for-javas-security-model/

Cheers,

Peter.


On 3/06/2021 7:33 pm, Ron Pressler wrote:
>
>> On 3 Jun 2021, at 00:41, Peter Firmstone <peter.firmstone at zeus.net.au> wrote:
>>
>>
>> StackWalker doesn't work with compiled code, only bytecode.
> If you’re referring to GraalVM’s Native Image, I don’t know about that problem and
> there does seem to be a relevant patch (https://github.com/oracle/graal/pull/734), but
> Native Image is a separate project from OpenJDK.
>
>> AccessController and AccessControlContext allow backward compatiblity for JAAS.   JAAS whether we like it or not, is the default authorisation layer framework.
>>
>> http://word-bits.flurg.com/jaas-is-terrible-and-there-is-no-escape-from-it/
> I don’t know how much a seven-year-old article, that predates Java 8 supports the use
> of the present tense, but in any event, the JEP says that JAAS will be preserved.
>
>> With SecurityManager gone, people will no longer assume it has sole responsible for Security
> People don’t assume that now, as secure software doesn’t employ it even today. People do,
> however, assume that the mechanism, if used, is robust enough to be used for security
> purposes.
>
>> OpenJDK devs won't carry a significant burden for it's maintenance.
> While the number of places where the JDK *implements* some “protected operation”, like
> opening a file or writing to a socket, is somewhat bounded — and so keeping some hooks
> in those places *might* be reasonable — the number of places that *use* those operations
> is not. Maintaining doPrivileged in that unbounded set of places is not an insignificant
> burden.
>
>
>> Any security issues will be the responsibility of third party implementations, like mine.
>> The JDK won't provide an implementation, just the framework.
> But the correct use of doPrivileged, if you’re proposing that it’s kept, must still be
> tested against *some* implementation, and OpenJDK would still need to fix bugs related
> to it.
>
>> Those of us using the Principle of Least Privilege can continue to do so
> Perhaps you believe that the only software in the world that applies Least Privilege is
> Java software that employs the Security Manager, but that is not how most people, including
> the person who had framed it two decades prior to the invention of the Security Manager,
> understand the principle.
>
> The original statement of the principle was: "Every program and every privileged user of
> the system should operate using the least amount of privilege necessary to complete the
> job.” (https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.226.3939)
>
> You are talking about applying the principle at a granularity of code units that are
> smaller than a program. It’s fine to believe that is worthwhile, but the principle
> certainly doesn’t require that every effort be expended to afford least privilege at
> any granularity.
>
>> and we can participate in OpenJDK to maintain Permission checks where we need them and preserve context where appropriate.
> I think you’re underestimating the magnitude of this work, which potentially interacts with
> each and every change in the JDK (and in practice interacts with many of them, and today it’s
> done by those who are responsible for the relevant change), which you’ll need to monitor,
> not to mention that OpenJDK Reviewers, a role granted only to the most experienced contributors,
> would still have to review that work.
>
> However, if you think that is an amount of work you could manage, perhaps it could be done
> outside the JDK using Java Agents.
>
>> JAAS will continue to remain functional
> The JEP already intends to keep JAAS functional, as far as I can tell.
>
> — Ron