I'm grateful for everyone's ideas and feedback, in the coming days &
weeks I'll put together some documentation to summarize and put some
time into some proposals, I have a lot of experience with the SM
infrastructure and its inner workings, having had to work around it's
pitfalls.
Watch this
On 8/3/21 8:10 PM, Peter Firmstone wrote:
On 4/08/2021 2:40 am, Sean Mullan wrote:
On 8/2/21 8:28 PM, Peter Firmstone wrote:
In JGDMS without SM, at least the following must be addressed to
maintain security:
1. TLS and Kerberos connections cannot be established. (My
software is
> 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 tha
2021/8/3 9:40:58 -0700, [email protected]:
> On 8/2/21 8:28 PM, Peter Firmstone wrote:
>> ...
>>
>> Having established that OpenJDK is not yet willing to compromise, I have
>> been attempting to create an authorization layer using Agents, so that I
>> can restore perimeter security following
On 08/03/21 12:40, Sean Mullan wrote:
> It is to the point where I only skim your emails
> quickly. I would take the time to write up your ideas in an external place.
> It may not go anywhere, but at least you would have a single place where
> your proposal, experiments, etc are documented.
I wou
Maybe we need some criteria, that defines what's not easily instrumented?
On 4/08/2021 10:19 am, 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 c
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 that OpenJDK is prepared to
support, then we will pick the most impo
On 4/08/2021 2:40 am, Sean Mullan wrote:
On 8/2/21 8:28 PM, Peter Firmstone wrote:
In JGDMS without SM, at least the following must be addressed to
maintain security:
1. TLS and Kerberos connections cannot be established. (My
software is
littered with doPrivileged calls that preserv
> 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
What you are proposing is:
1. Add an SPI for deep permission checks in the JDK.
2. Do so by changing the behaviour of existing classes in a non-trivial way.
3. Keep access checks in the JDK.
I do not speak for those who work on the security mechanisms, but I believe
that none one of these,
even
> 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 so
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 "dis
On 8/2/21 8:28 PM, Peter Firmstone wrote:
In JGDMS without SM, at least the following must be addressed to
maintain security:
1. TLS and Kerberos connections cannot be established. (My software is
littered with doPrivileged calls that preserve the Subject, we don't
have anon TLS
Can you think of any workable alternative compromises?
On 3/08/2021 9:21 pm, Ron Pressler wrote:
What you are proposing is:
1. Add an SPI for deep permission checks in the JDK.
2. Do so by changing the behaviour of existing classes in a non-trivial way.
3. Keep access checks in the JDK.
I do n
Wow, thanks Andrew,
There's certainly some complexity there, I appreciate your guidance.
Regards,
Peter.
On 3/08/2021 7:11 pm, Andrew Dinn wrote:
On 03/08/2021 02:30, Peter Firmstone wrote:
Just curious, when using Agents, what are the recommendations for
line numbers in code, for exceptions
Thanks Ron, reply inline.
On 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 I'd replace the inherited thread context
with an unprivilege
On 03/08/2021 02:30, Peter Firmstone wrote:
Just curious, when using Agents, what are the recommendations for line
numbers in code, for exceptions etc, how are these affected when
instrumenting?
For Byteman I use ASM to inject bytecode sequences into methods without
any (significant) modifica
On 3/08/2021 6:31 pm, Ron Pressler wrote:
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 menti
Just thought I'd share some thoughts around a couple of statements in
JEP 411:
*|java.security.{AccessController, AccessControlContext,
AccessControlException, DomainCombiner}|* — The primary APIs for the
access controller, which is the default implementation to which the
Security Ma
Thanks Ron,
What we do now is dynamic, so we need to figure out how to replicate
that post SM. Things we don't grant dynamically are good candidates for
command line argument options.
We basically authenticate, then authorize class loading dynamically at
runtime, along with other things, su
Hello Andrew,
Loss of SM is a significant threat to my software, if left unresolved.
Your interpretations are your own, I make no apologies for your
interpretation. I am describing the difficulties that I am experiencing
with JEP 411 migration and how it applies to my situation, it appears
t
On 02/08/2021 11:33, Peter Firmstone wrote:
I think you may be misinterpreting my comment, let me clarify:
Really? I'd suggest only if you stretch the meaning of your words beyond
their elastic limit.
I'm assuming that during the process of removal of security manager, any
external ports or
On 8/2/21 8:49 AM, Peter Firmstone wrote:
> If I fix that bug, will JEP 411 be cancelled?
No. The problem wasn't that we couldn't fix the [Speculative Execution
Vulnerabilities], more that any fix would be so invasive and pervasive
that it would severely hamper the whole platform.
--
Andrew Hale
Hello Andrew,
I think you may be misinterpreting my comment, let me clarify:
I'm assuming that during the process of removal of security manager, any
external ports or process hooks that we can only turn off now by not
granting a permission will be replaced by a command line property or
somet
On 01/08/2021 15:28, Uwe Schindler wrote:
I'm working on the assumption that OpenJDK will close any
external holes currently defended by permission checks. It would
be good if the JDK was secure by default, with properties
required to be set for allowing such things as agents,
management, parsin
Thanks Florian,
1. If I fix that bug, will JEP 411 be cancelled? BTW. Sparc isn't
vulnerable.
2. My primary use case is for SM is for authorization decisions for
remote users and services.
JSR-121: Java Application Isolation API Specification.
http://apt.cs.manchester.ac.uk/intranet/cso
* Peter Firmstone:
> From our discussions, my interpretation is that OpenJDK is constrained
> by corporate security policy; any issues with SecurityManager
> infrastructure will be treated as confidential security issues and
> have to be fixed with internal resources. Community volunteers won't
>
On 2/08/2021 4:48 am, Alan Bateman wrote:
On 01/08/2021 15:28, Uwe Schindler wrote:
:
What I figured out: You intend to remove SecurityManager because it
does not fit your latest ideas how Java threads should behave. I know
the main problem is not "SecurityManager is too complex / too slow /
On 01/08/2021 15:28, Uwe Schindler wrote:
:
What I figured out: You intend to remove SecurityManager because it does not fit your latest ideas
how Java threads should behave. I know the main problem is not "SecurityManager is too complex
/ too slow / wrongly used /..." -- the main problem of so
On 01.08.21 16:28, Uwe Schindler wrote:
The problem is: you deprecate for removal without offering any API to replace
the main pain points:
...
- Disable damn java serialization completely
JDK 9+ JVM flag / security property, see JEP 290
-Djdk.serialFilter=!*
regards,
michael
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 think
On 01.08.21 18:35, Michael Bien wrote:
On 01.08.21 16:28, Uwe Schindler wrote:
The problem is: you deprecate for removal without offering any API to
replace the main pain points:
...
- Disable damn java serialization completely
JDK 9+ JVM flag / security property, see JEP 290
-Djdk.serialFil
Hi Andrew,
> > I'm working on the assumption that OpenJDK will close any external holes
> > currently defended by permission checks. It would be good if the JDK
> > was secure by default, with properties required to be set for allowing
> > such things as agents, management, parsing xml and serial
On 01/08/2021 03:14, Peter Firmstone wrote:
I'm working on the assumption that OpenJDK will close any external holes
currently defended by permission checks. It would be good if the JDK
was secure by default, with properties required to be set for allowing
such things as agents, management, pa
Hi Ron,
So far we have dealt with CORBA (external library), pack200 (working on
an external lib) and to support Java 17, removed some Activation class
dependencies (we don't use RMID, so grabbed the missing Activation
classes from Apache Harmony), thankfully these were not challenging,
althou
I'm potentially watching many years of development efforts burn, due to
JEP 411 and trying to find a way to save it, I don't refer to it as
fun. Frustrating, infuriating, irritating, anger, that would more
accurately describe the emotions current circumstances create.
I'll be focusing only on
On 31/07/2021 04:04, Peter Firmstone wrote:
Allan has advised when finalizers are removed, it will be practical to
use Agents to instrument public API to implement an authorization
layer, this is try, so can it be coordinated with JEP 411 et al?
Our exchange was about instrumenting construct
The current JEP 411 plan of action, if left unchanged, will leave
developers who adopted the SM architecture as an authorization layer
unable to upgrade to later versions of Java, until finalizers and the
finalizer attack defensive methods in constructors are removed. JEP 411
has the potential
41 matches
Mail list logo
