RFR: 8315487: Security Providers Filter [v13]

[Xuelei Fan]

On Thu, Dec 12, 2024 at 1:20 PM Sean Mullan <sean.mullan at oracle.com> wrote:

> Xuelei,
>
> What value does a pluggable provider API provide?


With a public API, it is not necessary any longer for OpenJDK to maintain a
filter syntax.  If the filter syntax is supported, it will require JDK to
maintain and track the development of various crypto compliant policies.
If one cannot support FIPS or any other policies with the syntax, OpenJDK
security team could be blamed and asked for a bug fix or enhancement.
There is nothing else application can do to customize the syntax except ask
for help from OpenJDK security team.

If the team ready to shoulder the responsibility to support known and
unknown policies?  I am not sure.

Xuelei

Why would I want
> different implementations of an API that I want to use to disable SHA-1
> for example? Why would I want to learn more than one way to configure
> them? The details are always going to be in how the filter is
> configured, so ideally you want one way to do that, and one time to
> learn it. I think this is also the type of feature you want to have a
> large amount of confidence that it does the right thing since it will be
> used for security purposes.
>
> I'm all for making the implementation simpler though. If there are API
> changes we can make to centralize the filtering through a simpler API
> (that perhaps is final, and not extensible) and not having to modify
> each engine class to call it, that would be great.
>
> --Sean
>
> On 12/12/24 3:55 PM, Xue-Lei Andrew Fan wrote:
> > On Mon, 2 Dec 2024 21:05:53 GMT, Martin Balao <mbalao at openjdk.org>
> wrote:
> >
> >> getService/getServices API overrides are supported since the initial
> PR. Please check the JEP and implementation, and let us know if you see any
> flaw.
> >
> > I guess you refer to the following section in the JEP.  Otherwise,
> please let me know the correct JEP section.  That's the key point that I
> would like to address.  Without this concern, the issue could be simpler.
> >
> >> For third-party providers that override
> java.security.Provider::getService or java.security.Provider::getServices
> to return services that have not been evaluated against the filter or are
> evaluated and not allowed, a second filter enforcement occurs in
> java.security.Provider.Service::newInstance.
> >
> > For unknown providers that override the Provider::getService and
> Provider::getServices methods, I'm not sure how the filter could get them
> evaluated with the 1st filter.  For the 2nd filter, please refer to the
> next comment.
> >
> >> In rare situations, a third-party provider can override
> java.security.Provider.Service::newInstance and return an unvetted service
> implementation (SPI).
> >
> > Well, there is a concern of mine.  I don't agree the case is rare.  What
> if you are making a wrong judgment about it popularity here?  Did you have
> data to support your point.  How could you get the case covered even for
> the rare case even if it is really rare?
> >
> > With a new public API, for example ServicePermission.permit(Provider
> service).  I don't think you need the 2nd filter for
> java.security.Provider.Service::newInstance any longer.  All you need is to
> updates the following 2 or 3 methods, plus a few bug fixes out of the scope
> of this JEP:
> >      provider.putService() (optional, for performance improvement only)
> >      provider.getService()
> >      provider.getServices()
> >
> > And document the public API and have third party provider follow the
> spec and use the API.  Without a public API, there is not much we can do
> for unknown third party providers.   Even with the public API, third
> party's provider may not follow it.  But they now have a way to follow the
> spec, and application also have solutions for those that do not follow the
> new spec yet.
> >
> > Let's see the scenarios:
> > 1.  Define a public service API: ServicePermission.permit(Provider
> service), and a method to get the service so that it can be set with a
> security property (see #4).
> > 2. Update  provider.getService() and  provider.getServices(), and submit
> to JDK repository.
> > 3. Application implement the ServicePermission service,
> ThisIsMyFilterProvider (JDK could have a java.security property filter
> implementation in a new JEP, but it is not necessarily have any value in
> default JDK).
> > 4. Update java.security update,
> java.security.filter="ThisIsMyFilterProvider", default value is empty.
> > 5. Enjoy it.
> >
> >> are we going to have different syntax depending on the 3rd-party filter
> implementor?
> > No, there is not syntax to maintain at all, unless you want to define a
> specific ServicePermission provider.  You can do that with your proposal
> about the syntax for default JDK, and enforce it for your own proposal.
> You don't want to worry about those applications that don't use your
> proposal:
> > java.security.filter=my-filter-Provider-with-my-loved-syntax
> >
> >> The problems of filtering by algorithm parameters and by use (e.g. MD5
> for UUID) are not easy to solve, will require further discussion and are
> orthogonal to a pluggable filter.
> > No, it is not easy for your proposal.   But it is not that hard with a
> customizable ServicePermission.permit(Provider service) APIs.  I think
> smart developers could have it addressed for specific environment, so that
> we don't need to worry about them for a general approach for all
> environment.
> >
> > It looks like more simple, powerful and having actual requirements, is
> it?
> >
> > -------------
> >
> > PR Comment:
> https://git.openjdk.org/jdk/pull/15539#issuecomment-2539993473
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20241213/e3b85d22/attachment-0001.htm>