Re: A possible JEP to replace SecurityManager after JEP 411

On Tue, Apr 26, 2022 at 8:17 AM Mario Torre wrote: > I think there's a difference between "perceived" security and "actual" one. > > The SM in today's post Spectre, Meltdown and the likes world is > "perceived" security, which may lead to a relaxation on the security > of other layers because at

Re: A possible JEP to replace SecurityManager after JEP 411

On Tue, Apr 26, 2022 at 4:47 AM Alan Bateman wrote: > > On 25/04/2022 13:53, David Lloyd wrote: > > Nothing in the proposal causes splitting or delegation of > > responsibilities. It is _only_ about preserving security checkpoints > > in the JDK, which *add* a

Re: A possible JEP to replace SecurityManager after JEP 411

On Fri, Apr 22, 2022 at 10:04 PM Martin Balao wrote: > In my view, authorization decisions at higher layer generally > have better context, are more clear and less riskier. At a lower layer > there is more complexity and chances of both subtle combinations or > unseen paths that may lead to check

Re: A possible JEP to replace SecurityManager after JEP 411

On Fri, Apr 8, 2022 at 10:14 AM Sean Mullan wrote: > > Ok, thanks for some clarification on the proposal. > > How many applications currently depend on the SM for this type of usage? > What other alternate models have you considered? There are some number of customers and users within our user

Re: A possible JEP to replace SecurityManager after JEP 411

Small correction: On Fri, Apr 8, 2022 at 8:03 AM David Lloyd wrote: > Instead the API would exist to give containers and applications an > extra layer of authorization which does not exist today. Of course I meant "which would not exist after JEP 411". -- - DML • he/him

Re: A possible JEP to replace SecurityManager after JEP 411

Hi Sean, thanks for replying. I'll reply inline. On Thu, Apr 7, 2022 at 2:20 PM Sean Mullan wrote: > > With this proposal, as I understand it, the JDK would still be > responsible for maintaining and preserving essentially all of the > existing calls to the Security Manager (SM). I think we'd

Re: A possible JEP to replace SecurityManager after JEP 411

Thanks for responding Peter, I've commented inline below. On Tue, Apr 5, 2022 at 8:19 PM Peter Firmstone wrote: > > Thanks David, > > I'd certainly support such a proposal and encourage OpenJDK to consider > exploring it. > > Perhaps also consider; no privileges should be granted unless a >

A possible JEP to replace SecurityManager after JEP 411

Here at Red Hat there have been serious discussions about the impacts of security manager removal on our users, and whether there is an actual value impact, and if so, whether it can be mitigated or reversed somehow. We are interested in exploring whether we can come up with a way in which vendors

Re: JEP 411: Deprecation with removal would break most existing Java libraries

On Mon, Jun 14, 2021 at 6:47 PM Peter Firmstone wrote: > SecurityManager depends on Permission, currently there are Permission > checks throughout the JVM, however Permission implementation classes > will be removed, although the Permission class itself won't be. This is incorrect AFAICT. The

Re: JEP 411: Deprecation with removal would break most existing Java libraries

On Mon, Jun 14, 2021 at 2:38 AM Peter Firmstone wrote: > 1. Develop authorization layer security provider services in OpenJDK, > back port it to Java 8 and Java 11 (these provide most of the > utilised functionality of SecurityManager, allowing developers to > only implement those

Re: JEP 411: Missing use-case: user functions in an RDBMS

could stay with enough scaffolding for a third party (say, your extension) to be able to use their own stack-based access checker (made practical thanks to the new-ish StackWalker API). Anyway here it is: -- Forwarded message - From: David Lloyd Date: Sat, May 22, 2021 at

Re: New candidate JEP: 411: Deprecate the Security Manager for Removal

If it helps, we've solved this particular problem in a couple of places by using an MR-JAR which selects an implementation using `StackWalker` when Java 9+ is used. I will say however that it appears to be slightly less performant, which is unfortunate (but hopefully fixable at some point in the

Re: RFR: 8253368: TLS connection always receives close_notify exception

JDK, should we restrict it to the v1.3 > protocol or should we implement it based on a system property perhaps ? > > regards, > Sean. > > On 13/11/2020 17:11, David Lloyd wrote: > > How would a truncation attack be avoided in this case? > > > > On Fri, Nov 13, 2020 at 8:23 AM

Re: RFR: 8253368: TLS connection always receives close_notify exception

How would a truncation attack be avoided in this case? On Fri, Nov 13, 2020 at 8:23 AM Sean Coffey wrote: > > removing the "closing inbound before receiving peer's close_notify" exception > that can be seen with TLS stack if calling close on inbound. After reading > the relevant parts of the

Re: Reading from a closed socket: different behavior between Linux and other operating systems

This is, AFAICT, expected based on the differences between the socket layers of the various operating systems involved and their handling of closed sockets. If you write a similar test program in C using OS specific APIs, I believe you will see similar results. I don't think this is a problem

Re: RFR 6722928: Support SSPI as a native GSS-API provider

On Fri, Mar 22, 2019 at 10:29 AM Nico Williams wrote: > > On Thu, Mar 21, 2019 at 10:17:36PM +0100, Michael Osipov wrote: > > * header comment: Why do actually exclude NTLM from SPNEGO? Let SSPI work as > > it is intended to work. Means less code you have to maintain > > There's a few reasons: >

Re: Java SSLSocketChannel/SSLSelector?

On Fri, Mar 8, 2019 at 4:17 PM Andi Mullaraj wrote: > > Inline my comments but putting this upfront so that it doesn't go unnoticed > for the occasional reader: > > I was directed to this forum for discussing the merits and technicals details > of a possible SSLSelector/SSLSocketChannels. The

Re: Java SSLSocketChannel/SSLSelector?

On Sat, Feb 16, 2019 at 4:19 PM Andi Mullaraj wrote: > 2. What if someone decides to take the exact same approach to solve some > other higher-OSI-layer protocol decoding? Now you have to choose which kind > of protocol you want your selector to support. > > They create their own selector. I

Re: Fwd: Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable

On Wed, Oct 3, 2018 at 7:53 PM Sergey Bylokhov wrote: > Hi, Sean. > One question related to SecurityManager and performance, is it possible > to provide a special version of AccessController.doPrivileged which will > be noop if SecurityManager is not present? TBH that method (at least, the

Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable

On Sun, Sep 16, 2018 at 2:38 PM Will Sargent wrote: > > > The security manager is legacy these days and I think we need to figure out > > a plan how to deprecate and eventually bury it. > > I don't know of any research or papers that explicitly say that > SecurityManager is "legacy". I did

Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable

On Thu, Sep 13, 2018 at 3:03 PM Sean Mullan wrote: > > This is a SecurityManager related change which warrants some additional > details for its motivation. > > The current System.setSecurityManager() API allows a SecurityManager to > be set at run-time. However, because of this mutability, it

Re: SSLEngine weird behavior in 11+21?

On Thu, Jul 12, 2018 at 2:30 PM Xuelei Fan wrote: > On 7/12/2018 10:47 AM, Simone Bordet wrote: > > On Thu, Jul 12, 2018 at 4:34 PM Xuelei Fan wrote: [...] > >> In TLS 1.3, half-close policy is used. The server may not response with > >> the close_notify for client close_notify request. See

Re: JEP 332: Transport Layer Security (TLS) 1.3

Is it possible that this could make Java 11, or is that a long shot? On Fri, Mar 30, 2018 at 11:36 AM, wrote: > New JEP Candidate: http://openjdk.java.net/jeps/332 > > - Mark -- - DML

Re: Code Review Request: TLS 1.3 full handshake (JDK-8196584)

On Tue, Feb 20, 2018 at 1:57 PM, Xuelei Fan wrote: > In this implementation, I removed: > 1. the KRB5 cipher suite implementation. > Please let me know if you are still using KRB5 cipher suite. I may not add > them back if no objections. I am given to understand that we

Exploring an alternative AccessController implementation

This past weekend I took some time to try out an idea I've been kicking around for a couple of weeks: a pure-Java (no native) AccessController implementation [1]. •Rationale• I have a number of reasons for attempting this enhancement. • I think it would be beneficial (security-wise) if access

Re: Eliminating the security overhead when not running with a security manager

On Tue, Nov 21, 2017 at 5:41 AM, Alan Bateman <alan.bate...@oracle.com> wrote: > On 21/11/2017 00:48, David Lloyd wrote: >> >> One thing that springs to mind. Some allowance would have to be made >> for domain combiners and JAAS Subject propagation: this mechanism

Re: Eliminating the security overhead when not running with a security manager

One thing that springs to mind. Some allowance would have to be made for domain combiners and JAAS Subject propagation: this mechanism also uses access control contexts, to its own great detriment. I would say that the JAAS domain combiner strategy should be dropped in favor of a simple thread

Re: Code Review Request: JDK-6491070 (Support for RFC 5929-Channel Bindings)

I can say that from the perspective of SASL that we don't need any special indication about handshake, and it would be much easier to just read the material off of the engine, socket, or session as appropriate. On Thu, Aug 31, 2017 at 8:32 PM, Xuelei Fan wrote: > The