jjacobs207 wrote: ↑Tue Apr 02, 2024 11:07 pm
- Is this being overly secure?
That depends on what you're storing in the certificate store and why your company feels the need to keep it secured.
My experience is that people who take the attitude of keeping it secured usually can't answer that question. They just keep it secured because "IBM must have set it that way for a reason" and don't really understand what's going on, so they secure it needlessly.
But I have no way of knowing why you're doing it.
I have had people bring in a security expert such as Robert Andrews in the past and so far, at least, everyone ended up granting access to *public or at least to the users that need to run it. But again, I don't know what you're storing in it or why. Maybe you're a military organization that uses that keystore file to store top secret crypto keys... in that case, it should definitely be kept restricted.
This is not a decision someone else can make for you. Your company needs to understand the risks and make its own decision.
jjacobs207 wrote: ↑Tue Apr 02, 2024 11:07 pm
- Is it required for *PUBLIC to have the authority regardless?
Not at all. It's a requirement for the users who need to run programs that perform SSL encryption to have access. It provides access to the necessary cryptographic keys to do the encryption.
Also note that this has absolutely NOTHING to do with HTTPAPI, aside from th fact that HTTPAPI uses the crypto routines that come with the operating system. This is 100% an IBM i operating system question.
That's why users like QSYS, QLWISVR and QTMHHTTP have access, so that the server applications that IBM provides can do SSL.
jjacobs207 wrote: ↑Tue Apr 02, 2024 11:07 pm
- If I use a program that executes HTTPAPI and I make its owner QPGMR, USRPRF *OWNER, USEADPAUT *YES and QPGMR has *ALLOBJ, will that solve the problem?
- If so, would this be a recommended solution or a horrible idea?
- If my solution is a horrible idea, what better solutions do you have?
That wouldn't work because usrprf *owner and adopted authority have no impact on IFS objects.
You would have to use profile swapping if you wanted to bypass the need to grant users access to the SSL crypto key stores. That would work, but imho, it's 100x less secure than just giving the users access.
Granting the users access to this file means that they can utilize any SSL certificates (and related crypto keys) you've stored in there. That means one of your users could potentially steal your SSL certificates and use them on another machine. If you use the crypto keys for something besides SSL (such as validating that an application is genuine) they could also use them for that. That is the risk at hand. (Note that most other OSes give users access to the certificates by default.)
By contrast, using profile swapping (or adopted authority if it would work, which it wont) could potentially allow them to find a way to insert their own commands being run under the elevated authority. This would essentially allow them to do ANYTHING on the system, which I personally would say is much more dangerous than just giving them access to your SSL certificates.