Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8272317: jstatd has dependency on Security Manager which needs to be removed #6919

Closed
wants to merge 8 commits into from

Conversation

kevinjwalls
Copy link
Contributor

@kevinjwalls kevinjwalls commented Dec 22, 2021

Remove the use of Security Manager from jstatd.
Add use of an ObjectInputFilter to restrict RMI.

Also we can undo the property-setting Launcher.gmk change from: 8279007: jstatd fails to start because SecurityManager is disabled
..as that is no longer needed.

Docs/man page update to follow (JDK-8278619).


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed
  • Change requires a CSR request to be approved

Issues

  • JDK-8272317: jstatd has dependency on Security Manager which needs to be removed
  • JDK-8279891: jstatd has dependency on Security Manager which needs to be removed (CSR)

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/6919/head:pull/6919
$ git checkout pull/6919

Update a local copy of the PR:
$ git checkout pull/6919
$ git pull https://git.openjdk.java.net/jdk pull/6919/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 6919

View PR using the GUI difftool:
$ git pr show -t 6919

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/6919.diff

@kevinjwalls
Copy link
Contributor Author

/label serviceability

@bridgekeeper
Copy link

bridgekeeper bot commented Dec 22, 2021

👋 Welcome back kevinw! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk openjdk bot added rfr Pull request is ready for review serviceability serviceability-dev@openjdk.org labels Dec 22, 2021
@openjdk
Copy link

openjdk bot commented Dec 22, 2021

@kevinjwalls
The serviceability label was successfully added.

@mlbridge
Copy link

mlbridge bot commented Dec 22, 2021

Webrevs

@mlbridge
Copy link

mlbridge bot commented Dec 22, 2021

Mailing list message from Bernd Eckenfels on serviceability-dev:

Hello,

Is it safe to allow generic proxy objects, could they not execute arbritrary backend methods? Are the invocation handlers filtered indirectly?

What about those inner classes, are they stable? Could the whole protocol maybe changed to a different protocol?

Gruss
Bernd

--
http://bernd.eckenfels.net
________________________________
Von: serviceability-dev <serviceability-dev-retn at openjdk.java.net> im Auftrag von Kevin Walls <kevinw at openjdk.java.net>
Gesendet: Wednesday, December 22, 2021 7:22:26 PM
An: serviceability-dev at openjdk.java.net <serviceability-dev at openjdk.java.net>
Betreff: RFR: 8272317: jstatd has dependency on Security Manager which needs to be removed

Remove the use of Security Manager from jstatd.
Add use of an ObjectInputFilter to restrict RMI.

Also we can undo the property-setting Launcher.gmk change from: 8279007: jstatd fails to start because SecurityManager is disabled
..as that is no longer needed.

Docs/man page update to follow (JDK-8278619).

-------------

Commit messages:
- Remove jstad launcher property setting to allow Security Manager.
- Merge remote-tracking branch 'upstream/master' into 8272317_jstatd_secmgr
- Add ObjectInputFilter
- Merge remote-tracking branch 'upstream/master' into 8272317_jstatd_secmgr
- 8272317: jstatd has dependency on Security Manager which needs to be removed

Changes: https://git.openjdk.java.net/jdk/pull/6919/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6919&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8272317
Stats: 27 lines in 4 files changed: 4 ins; 15 del; 8 mod
Patch: https://git.openjdk.java.net/jdk/pull/6919.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/6919/head:pull/6919

PR: https://git.openjdk.java.net/jdk/pull/6919
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20211222/dfe85dab/attachment-0001.htm>

@@ -47,6 +48,8 @@
private static boolean startRegistry = true;
private static RemoteHost remoteHost;

private static final String rmiFilterPattern = "sun.jvmstat.monitor.remote.RemoteVm;com.sun.proxy.jdk.proxy1.$Proxy1;com.sun.proxy.jdk.proxy1.$Proxy2;java.lang.reflect.Proxy;java.rmi.server.RemoteObjectInvocationHandler;java.rmi.server.RemoteObject;!*";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The class name of the dynamic proxy is generated at runtime and can be different. As Bernd commented, the proxy classes cannot/should not be listed in the filter pattern.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK thanks - I was trying the minimal pattern to overcome rejections such as the following, captured in logs on different runs:

ObjectInputFilter REJECTED: class com.sun.proxy.jdk.proxy1.$Proxy1, array length: -1, nRefs: 2, depth: 1, bytes: 84, ex: n/a

ObjectInputFilter REJECTED: class com.sun.proxy.jdk.proxy1.$Proxy2, array length: -1, nRefs: 2, depth: 1, bytes: 84, ex: n/a

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the proxy classes need to be there. The RemoteHost API has a parameter of type RemoteVm which is a stub to an RMI remote object, which consists of a proxy and a handler. The proxy's interface list is filtered by the serialization filter so somebody can't just pass a proxy for anything.

The name of the proxy class probably does need to be wildcarded though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mlchung The Proxy class passed to the filter has been created in this VM from the interfaces listed.
The interfaces have already been filtered prior to creating the proxy.
The Proxy classes can safely be allowed based on a wildcard of the name. (As Stuart said).

@seanjmullan
Copy link
Member

/label security

@openjdk openjdk bot added the security security-dev@openjdk.org label Dec 23, 2021
@openjdk
Copy link

openjdk bot commented Dec 23, 2021

@seanjmullan
The security label was successfully added.

@kevinjwalls
Copy link
Contributor Author

Thanks for the comments -

The proxy objects are needed in the filter for this to work at all.

The proxy names/numbers and innner class names/numbers are predictable and stable IF we are using jstatd and jstat as standalone programs.

But they are unstable if there is other relevant activity in the VM process, e.g. a JMX connection comes in before they are created. We should wildcard the proxy names to work in such a situation: com.sun.proxy.jdk.proxy*

I'll mention also that jstatd has always been an experimental feature. The man page warns about lack of authentication and advises usage with caution.

…n this JVM changes the nameing/numbering of proxy classes.
@openjdk openjdk bot added csr Pull request needs approved CSR before integration and removed csr Pull request needs approved CSR before integration labels Jan 12, 2022
@kevinjwalls
Copy link
Contributor Author

CSR has been approved (https://bugs.openjdk.java.net/browse/JDK-8279891)

@mlchung
Copy link
Member

mlchung commented Jan 19, 2022

Are all the proxy interfaces public? The package in which a proxy class is created may be different depending if whether any proxy interface is in a non-exported and non-open package. com.sun.proxy.jdk.proxy* is the package for non-exported proxy classes. The proxy classes may be public in an unconditionally exported package [1] and its package name is jdk.proxy*.

[1] https://download.java.net/java/early_access/jdk18/docs/api/java.base/java/lang/reflect/Proxy.html#membership

@kevinjwalls
Copy link
Contributor Author

Are all the proxy interfaces public?

sun.jvmstat.monitor.remote.RemoteVm is "public interface RemoteVm extends Remote" and methods in there only return basic types.
This is in the jdk.jstatd module, where I see the module info contains "exports sun.jvmstat.monitor.remote to java.rmi;"

The only other names permitted are proxy/reflect/rmi related.

@mlchung
Copy link
Member

mlchung commented Jan 20, 2022

If sun.jvmstat.monitor.remote.RemoteVm is the only proxy interface, com.sun.proxy.jdk.proxy* should adequately cover the proxy classes created for RemoteVm.

@kevinjwalls
Copy link
Contributor Author

If sun.jvmstat.monitor.remote.RemoteVm is the only proxy interface, com.sun.proxy.jdk.proxy* should adequately cover the proxy classes created for RemoteVm.

Thanks. With that endorsement I think there are no unresolved issues with this change.

@openjdk
Copy link

openjdk bot commented Jan 27, 2022

@kevinjwalls This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8272317: jstatd has dependency on Security Manager which needs to be removed

Reviewed-by: cjplummer, rriggs

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been no new commits pushed to the master branch. If another commit should be pushed before you perform the /integrate command, your PR will be automatically rebased. If you prefer to avoid any potential automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Jan 27, 2022
Copy link
Contributor

@RogerRiggs RogerRiggs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@kevinjwalls
Copy link
Contributor Author

Many thanks Chris, Roger!

@kevinjwalls
Copy link
Contributor Author

/integrate

@openjdk
Copy link

openjdk bot commented Jan 28, 2022

Going to push as commit cb8a82e.
Since your change was applied there has been 1 commit pushed to the master branch:

  • 6de90ad: 8280863: Update build README to reflect that MSYS2 is supported

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Jan 28, 2022
@openjdk openjdk bot closed this Jan 28, 2022
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Jan 28, 2022
@openjdk
Copy link

openjdk bot commented Jan 28, 2022

@kevinjwalls Pushed as commit cb8a82e.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
integrated Pull request has been integrated security security-dev@openjdk.org serviceability serviceability-dev@openjdk.org
Development

Successfully merging this pull request may close these issues.

6 participants