> On 4 Aug 2021, at 01:19, Peter Firmstone wrote:
>
> Excellent, Ron, that's exactly what I'm after.
>
> I need to be able to implement an authorization layer on top of the JDK, but
> reach down into the JDK to use authorization to control access.
>
> Can we find out how many such checks
> On 3 Aug 2021, at 12:50, Peter Firmstone wrote:
>
> Can you think of any workable alternative compromises?
If you mean a compromise between no access checks in the JDK and all access
checks in the JDK, then yes,
which is possibly some callbacks for a small subset of operations that perform
> On 3 Aug 2021, at 06:48, Peter Firmstone wrote:
>
>
> We can still use these without an SM, Policy or Permissions for authorization
> decisions, as mentioned previously I'd replace the inherited thread context
> with an unprivileged context, and also allow the stack walk to be disabled
> On 3 Aug 2021, at 09:39, Peter Firmstone wrote:
>
>
>
> Can you elaborate? A Runnable, similar to registering a shutdown hook?
>
Maybe, but there have been no specifics beyond saying that something like that,
and
which requires that level of effort, might, after the dust settles and
3/08/2021 6:48 pm, Ron Pressler wrote:
>>
>>> On 3 Aug 2021, at 06:48, Peter Firmstone
>>> wrote:
>>>
>>>
>>> We can still use these without an SM, Policy or Permissions for
>>> authorization decisions, as mentioned previously
> On 3 Aug 2021, at 02:30, Peter Firmstone wrote:
>
>
> I am still hopeful that OpenJDK might create some hooks for us and keep the
> AccessController, AccessControlContext and Subject.doAs methods to make
> supporting all Java versions easier.
When I mentioned “hooks” I was referring to
Our path to making Java more secure is, indeed, similar to what you’re
proposing.
The general direction is that the application, rather than the libraries, will
have the final say on security-sensitive capabilities.
Just as strong encapsulation is now on by default, other things, such as native
Hi.
JEP 411 says that there is a feature whose value in fulfilling its purpose no
longer justifies its high cost, and so it should be removed. What you’re saying
is, that’s true, but you should keep it, anyway. Why? Because it can be put to
some other, more modest, accidental uses.
Now, the
Hi Peter.
- JEP 411, like every spec-changing JEP, is meant to allow those that use the
removed functionality
a migration path forward. The API elements that are deprecated for removal have
some years before
they are actually removed, so there’s nothing too urgent other than beginning
to
The JEP addresses this:
> In future JDK releases, we will degrade the Security Manager APIs so that
> they
remain in place but have limited or no functionality. ... This will allow
libraries
that support the Security Manager and were compiled against previous Java
releases
to continue to
-javas-security-model/__;!!GqivPVa7Brio!MWpnS_ogZx24MskkZbSSrZ7ZbtCSyNeEswy1gegVSzGdDe4Qpmdy0ocIje9M4Wtv3A$
>
> Cheers,
>
> Peter.
>
>
> On 3/06/2021 7:33 pm, Ron Pressler wrote:
>>
>>> On 3 Jun 2021, at 00:41, Peter Firmstone
>>> wrote:
>>>
>>>
>>> StackW
> On 3 Jun 2021, at 00:41, Peter Firmstone 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
That depends what you mean by “acceptable.” You can maintain a version of the
Java SE spec that
contains the Security Manager forever. If you want to add the SecurityManager
to a version of
the spec that doesn’t contain it (or contains it but behaves in a degraded
manner) then that
will not
> On 31 May 2021, at 22:53, Chapman Flack wrote:
>
>
> I am not sure what you are getting at with goal 3. Will the warning
> phone home?
No, but it will make users aware, and that awareness can be measured or
estimated.
>
> I am also sort of wondering what's to become of some of the
The deprecation warnings serve three purposes:
1. Help software maintainers know about the deprecation.
2. Help software users (the more tech-literate ones, those who look at logs)
know when the software they use has properly addressed the issue.
3. Help us better gauge, however imperfectly
Hi.
Before getting into alternatives and the vision for what would be possible
post-SecurityManager, it would help to explain what the use-case and
requirements are.
When we talk about untrusted code we usually mean code that you believe
might be malicious and intentionally try to break through
> Gruss
> Bernd
>
>
> --
> http://bernd.eckenfels.net
> Von: security-dev im Auftrag von Peter
> Tribble
> Gesendet: Saturday, May 22, 2021 11:11:43 AM
> An: Ron Pressler
> Cc: Peter Firmstone ; David Black
> ; Alan Bateman ;
> security-dev@openjdk.java.
iscussion, that there would at least be an
> understanding of what OpenJDK is so hastily choosing to destroy.
>
> Once it is gone, it will be irretrievable, it will never be possible to lock
> down the JVM so securely again.
>
>
> On 21/05/2021 11:06 pm, Ron Pressler wrote:
>>
> On 21 May 2021, at 12:52, Peter Firmstone wrote:
>
> It's quite clear this will be pushed through anyway,
>
No, not *anyway*, but given the fact that the community consists of millions of
users, this
proposal has been well-publicised, only very few people have voiced objections,
fewer
> On 21 May 2021, at 11:29, Peter Firmstone wrote:
>
>
> Can you share this list please? If I see anything missing I can add it for
> you.
No, because this might give the false impression that this is a debate. In a
community
of millions, almost no decision will be universally accepted.
> On 21 May 2021, at 04:55, Peter Firmstone wrote:
>
>
> Yes everything is a compromise and there are trade-offs. The way I see it,
> the cheapest way to maintain security is to find others who share a common
> pain point is to maintain a copy of OpenJDK focused on security. We can
>
> On 18 May 2021, at 07:10, David Black wrote:
>
>
> I hope you aren't being rude on purpose by continuing to 1) top post
> and 2) not ignore various parts of my emails.
>
This isn’t a debate forum. We’re trying to collect information, not
to convince every last person. I respond to what I
> On 18 May 2021, at 12:27, Peter Firmstone wrote:
>
>
> However I disagree that the Principle of least privilege is wrong headed, I
> think you've been discussing sandbox concepts with the experts and they're
> going to tell you that's a bad idea. But the two aren't the same, one is
>
> On 18 May 2021, at 03:39, Peter Firmstone wrote:
>
>
> Is it also possible to consider directing file access and network access
> through single points of access? This will simplify the process so we don't
> need to scour the entire codebase for usages.
>
Of all your suggestions, I
> On 18 May 2021, at 01:11, Peter Firmstone wrote:
>
> Your ideas are great in theory, in practice, the problem with your Agent
> proposal is every JVM release needs to be reviewed, and we have to review
> Java's internal implementation code, and understand it in order to instrument
> it.
is required. What’s required is a reexamination of
security-per-hour-effort gained by trying to assign different permissions to
different code sources.
— Ron
> On 18 May 2021, at 01:02, David Black wrote:
>
> Hi Ron,
>
> On Mon, 17 May 2021 at 21:38, Ron Pressler wrote:
>>
>&
> On 17 May 2021, at 21:46, Peter Firmstone wrote:
>
>
> Yes, you are talking about those who maintain and develop OpenJDK, but this
> is only a small proportion of the overall Java developer ecosystem.
Not at all. I’m talking about the millions of developers who don’t get what
they
> On 17 May 2021, at 13:47, Peter Firmstone wrote:
>
> It is a foundational feature, it has a significant impact on those who
> adopted it.
True. But the problem is that it also has a significant impact on those who
didn’t.
>
>
> This is an existing system, your arguments are not
mechanism than the Security Manager.
— Ron
> On 17 May 2021, at 03:11, David Black wrote:
>
> Hi Ron
>
> On Thu, 13 May 2021 at 20:22, Ron Pressler wrote:
>>
>>
>>
>>> On 13 May 2021, at 03:11, David Black wrote:
>>>
>>>
>
> On 17 May 2021, at 06:19, Peter Firmstone wrote:
>
>
> 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).
> On 13 May 2021, at 03:11, David Black 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
> On 13 May 2021, at 10:32, Peter Firmstone wrote:
>
> So it targets 17.
I don’t know. I think that’s still TBD, but perhaps others know more.
>
> It would be nice to have certainty about which release it will be removed
> from, for planning purposes. Again it would seem that this isn't
ct Services Pty Ltd.
>
> On 13/05/2021 7:43 am, Ron Pressler wrote:
>>
>>> On 8 May 2021, at 05:55, Peter Firmstone
>>> wrote:
>>>
>>> What would help in future:
>>>
>>> • Define a core Java api, a javadoc anno
P.S.
Sorry, I just realised I used the word “process” in 1 and 2 with different
meanings. In 1 I meant an
OS process running Java; in 2 I merely meant a Java mechanism (as opposed to an
OS mechanism).
> On 12 May 2021, at 22:49, Ron Pressler wrote:
>
>
>
>> On 12 May 202
> On 12 May 2021, at 22:41, Peter Tribble wrote:
>
>
> Let me give a concrete example:
>
> Parsing and rendering a PDF file that may contain references to fonts or
> other resources.
> We know exactly where the files are installed, so wish to allow the rendering
> routine access
> to the
> On 8 May 2021, at 05:55, Peter Firmstone wrote:
>
> What would help in future:
>
> • Define a core Java api, a javadoc annotation? If parts of it are
> deprecated, they will not be removed for eg 3 LTS releases, pick a number, it
> provides certainty. Developers writing new
> On 12 May 2021, at 21:46, Peter Tribble wrote:
>
> We're (partly, at least) in that group. We can't block the access from outside
> the JVM (and we are containerized with restricted permissions already) because
> some accesses are legitimate - something outside the JVM doesn't know when
>
that saying that “move fast and break things” is the new philosophy is
not only unfair, but very, very far
from the truth.
— Ron
> On 7 May 2021, at 23:20, Peter Firmstone wrote:
>
>
> On 8/05/2021 4:21 am, Ron Pressler wrote:
>> Deprecation/removal JEPs, and this one is
of certain trademarked names. I don't know where you can obtain advice
on such matters.
— Ron
> On 7 May 2021, at 11:17, Peter Firmstone wrote:
>
>
> On 6/05/2021 9:46 pm, Ron Pressler wrote:
>>
>> Trying to convince people, at this point, after twenty five years that
> On 6 May 2021, at 11:26, Peter Firmstone wrote:
>
> OpenJDK seems to have assumed that no one was using SecurityManager based on
> one research report. There's a lot of closed source java code out there, I
> suspect most of our users are closed source. I don't know exactly how many
>
> On 5 May 2021, at 05:04, Peter Firmstone wrote:
>
> A VALUABLE LESSON FOR ANY JAVA DEVELOPER: DON'T PUBLISH ANY java.* package
> namespace API'S THAT MAY BE AT RISK OF LATER REMOVAL IN YOUR API, java.*
> API's ONCE REMOVED CANNOT BE REPLACED. IF YOU ARE CONCERNED SOMETHING MAY BE
>
Resent with plain-text formatting (I hope) & corrections/rephrasing
> On 4 May 2021, at 03:49, Peter Firmstone wrote:
>
>
> Yes, I'm sure millions of developers don't use the security infrastructure
> because they only have low value data to protect, or it belongs to someone
> else and
On 4 May 2021, at 03:49, Peter Firmstone
mailto:peter.firmst...@zeus.net.au>> wrote:
Yes, I'm sure millions of developers don't use the security infrastructure
because they only have low value data to protect, or it belongs to someone else
and developers that do, can use it incorrectly,
On 29 Apr 2021, at 13:06, Peter Firmstone
mailto:peter.firmst...@zeus.net.au>> wrote:
Is there a simpler way to limit permissions of library code?
Limiting permissions of library code is a spectacular idea, and the
stack-dependent deep sandbox offered by the Security Manager
is the most
worrisome they should be handled
by components that can actually get the job done better than the SM.
— Ron
On 23 Apr 2021, at 14:41, Reinier Zwitserloot
mailto:rein...@zwitserloot.com>> wrote:
> Ron Pressler wrote:
> The problem is that this is not doable with the Security Man
On 22 Apr 2021, at 18:27, Reinier Zwitserloot
mailto:rein...@zwitserloot.com>> wrote:
For example, I may want to restrict access to the 'logs' directory. I can't
restrict it at the OS level (because the JVM does need to write the log files,
of course), at best I can restrict it at the module
already too late since when
> you see the log, it has already happened.
>
> I would like to ask in this scenario, what is the best possible
> solution to mitigate it for the end user perspective besides not
> downloading it since it can be included implicitly as a dependency
nloading it since it can be included implicitly as a dependency,
and how can I help the end user to mitigate this scenario?
- Lim
On Wed, Apr 21, 2021 at 4:24 PM Ron Pressler
mailto:ron.press...@oracle.com>> wrote:
Monitoring network connections can be done with JFR. It will tell
Monitoring network connections can be done with JFR. It will tell you which
classes
perform the connections. It does not require a Java agent.
Setting up the SM to *block* connections while also not allowing those
libraries to
disable the SM is not very easy. Those libraries are trusted, and
library for network access would let you figure out, quickly,
> that ZXING is not doing what you thought it did.
>
> NB: Just to be clear, zxing _does not_ make any network calls. The library
> generates PNGs with QR codes as you would expect. But it makes for a
> plau
I think it’s worth adding that treating libraries as untrusted code is
unworkable over the long run, as their set of permissions possibly
needs to be reexamined with every update. On the other hand, JFR can serve as a
mechanism for tracing application behaviour, which,
when streamed, can serve
51 matches
Mail list logo
