A client user requires access to ICSF when calling ZSS endpoints

[JirkaAichler]

Describe the bug
When a client calls ZSS REST APIs the SSL connection is established under the server user. Then the context is switched to the client user (impersonification) and the native APIs are called under the client user. ZSS does not switch back to the server user when sending the HTTP response. It leads to the following error when the client user has no access to ICSF:

socketWrite: tlsWrite failed with status: 456 (ICSF callable service returned an IO error while writing, errno=0 reason=0                                        
                Aborting...  

This permission should not be required from a client user. ZSS should switch back to the server user before sending the response.

Client-side will not receive any response and the connection is never closed.

[JoeNemo]

This sounds reproducible. Can we get a simple CURL/POSTMAN-like example to drive this?

[JoeNemo]

Zowe may have to require all users to have access to run ICSF code, too.

[JirkaAichler]

I can send HTTPie format :-)

http post https://system.net:7557/certificate/dn "Cookie:%token%" dn=test_1 registry=oidc.com

It was reproduced only with ACF2. Not saying it couldn't happen under other ESMs. My other testing environments could just be less restrictive.

[JirkaAichler]

Zowe may have to require all users to have access to run ICSF code, too.

We should stay as close to requirements on z/OS (IRR.IDIDMAP.QUERY) to follow the least privilege access principle. Giving every client access to ICSF can be misused,

By the way, I still was not able to figure out what exact ICSF permission I need.

[JirkaAichler]

The required permission is class CSFSERV and resource CSF1SKE. This is PKCS #11 Secret key encrypt. We definitely should not require this access from a client user.

[Joe-Winchester]

Adding in comments from Onno on slack (to stop them being lost when they page out from the slack workspace).

The provider mentioned earlier java.protocol.handler.pkgs=com.ibm.crypto.hdwrCCA.provider, seems to be J11 or so, as when we wrote it up for J8, it was security.provider.1=com.ibm.crypto.hdwrCCA.provider.IBMJCECCA`
(in /usr/lpp/java/J8.0/lib/security/java.security)
the JCECCARACFKS type stays the same.
some gotcha's I know off

• ICSF checks profiles in the CSFKEYS and CSFSERV classes
  with ICSF in play, security checks are at thread level, so if you switch security context for a thread, the thread userid needs the permit
• if I recall correctly, system SSL (GSK*) does not require anything special for ICSF usage (the user still needs the CSF* permits though)

[jthyssenrocket]

My recommendation is to turn AUDIT on the CSFSERV class, start Zowe, logon with a regular user, and launch various apps.
Collect the audit data and summarize.

I've done this exercise for IBM Unified Management Server running under Zowe, but I am unsure how many apply to a plain vanilla Zowe.
My findings were:

Zowe STC (I run launcher, ZIS, and ZIS AUX under the same STC userid)

            READ on CSFSERV CSF1TRC
            READ on CSFSERV CSF1SKE
            READ on CSFSERV CSF1SKD
            READ on CSFSERV CSFDSG
            READ on CSFSERV CSFIQA
            READ on CSFSERV CSFRNG

End user
READ on on CSFSERV CSF1SKE

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs, but can be reopened if needed. Thank you for your contributions.

[JirkaAichler]

Do not close. A client should not need READ on CSFSERV CSF1SKE. It would be a security problem.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs, but can be reopened if needed. Thank you for your contributions.

[JoeNemo]

As far as I know there is no project/PR to make this additional requirement on the security config. Can we close? Is this a dead issue now?

[JirkaAichler]

I still consider it a security risk that clients require access to a private key that should be available only to a server user.

Feel free to do anything with this issue based on your best judgment.

[jthyssenrocket]

I agree, it is a security exposure and it should be fixed (rather sooner than later).

[JoeNemo]

Point taken. This still is a bug.