<div dir="auto">OpenSSL is a toolkit, not a full implementation.  More importantly, it is a library, so anyone who can link against it can perform all operations that the library can support, and the library has no concept of role separation built in.<div dir="auto"><br></div><div dir="auto">As such, the 'openssl' commandline tool allows the use of any of its subcommands by anyone who can run their executables.  This generally includes 'root', which is also usually necessary for manipulating files (keys, certs, and CA cert chains) which are owned by system users, like 'apache'.</div><div dir="auto"><br></div><div dir="auto">There are many openssl subcommands which are useful for standard system and network administrators.  s_client and s_server (to verify interoperability and connectivity), x509 (to figure out what's broken and see if it's something the PKI admin needs to deal with, in conjunction with the -noout and -text parameters), verify (to figure out what's wrong with a cert chain to make filing tickets for the pki admin more useful)... the only commands I can really think of off the top of my head that could be legitimately restricted are 'req' and 'ca'.  Usually, the 'ca' command is limited by access to the CA key.  'req' generates a new certificate signing request, but doesn't generate a new certificate.  The operations for a PKI admin should in all cases include "generate your request, then send the request that you just generated" rather than "submit some request that some other schlub generated", which mitigates that particular potential disaster.</div><div dir="auto"><br></div><div dir="auto">It might be possible to limit the execution of openssl subcommands using SELinux roles and labels, but I don't think anyone's audited the subcommands looking for functionality that should be limited to one role or another.  The closest that's been done has been for the FIPS validation, and (to my uncertain understanding) even that applies pretty much only to the building and installation of the module.</div><div dir="auto"><br></div><div dir="auto">If you do perform such an audit, I'd love to see your work.  (n.b. I'm not a member of the OpenSSL team, so my opinions are mgmy own and no one else's.)</div><div dir="auto"><br></div><div dir="auto">-Kyle H</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Sep 15, 2019, 09:06 Jimmy Jung <<a href="mailto:jimmy.jung@slandala.com">jimmy.jung@slandala.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="m_690854885899598337WordSection1">
<p class="MsoNormal">I had been poking around the internet looking for implementations of Role Separation for OpenSSL (in this case in Centos).  I thought I should ask here as well. 
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">By “role separation” I’m thinking that only PKI roles can perform OpenSSL commands and system admins are restricted from these operations.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thanks<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">jimmy<u></u><u></u></p>
</div>
</div>

</blockquote></div>