Role Separation

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Role Separation

Jimmy Jung

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. 

 

By “role separation” I’m thinking that only PKI roles can perform OpenSSL commands and system admins are restricted from these operations.

 

Thanks

 

jimmy

Reply | Threaded
Open this post in threaded view
|

Re: Role Separation

Kyle Hamilton
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.

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'.

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.

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.

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.)

-Kyle H

On Sun, Sep 15, 2019, 09:06 Jimmy Jung <[hidden email]> wrote:

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. 

 

By “role separation” I’m thinking that only PKI roles can perform OpenSSL commands and system admins are restricted from these operations.

 

Thanks

 

jimmy

Reply | Threaded
Open this post in threaded view
|

Re: Role Separation

JordanBrown
On 9/15/2019 8:29 AM, Kyle Hamilton wrote:
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.

Still more importantly, almost everything OpenSSL does is just math and file manipulation.  S_client and s_server add basic network operations.  There's probably some low-level goop for hardware acceleration, but that's just acceleration.

You can write a program to do those things without needing to involve OpenSSL, so restrictions on OpenSSL per se aren't very interesting.

The way to restrict PKI operations (in a simple configuration) is through file and directory permissions on the data involved.
-- 
Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris