Open JirkaAichler opened 1 year ago
This sounds reproducible. Can we get a simple CURL/POSTMAN-like example to drive this?
Zowe may have to require all users to have access to run ICSF code, too.
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.
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.
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.
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
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 permitMy 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
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.
Do not close. A client should not need READ on CSFSERV CSF1SKE. It would be a security problem.
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.
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?
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.
I agree, it is a security exposure and it should be fixed (rather sooner than later).
Point taken. This still is a bug.
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:
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.