Bug 1032305 - Problems with certificates using LMIshell as local client
Problems with certificates using LMIshell as local client
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: openlmi-tools (Show other bugs)
20
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Peter Hatina
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-19 18:34 EST by Russell Doty
Modified: 2013-12-10 06:57 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-10 06:57:33 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Russell Doty 2013-11-19 18:34:57 EST
Description of problem:

Problems using lmishell as a local client (lmi client and server running on the same system).

1. Attempting to use lmishell from user account:

$ lmi hwinfo
username: root
password: 
ERROR: failed to make a connection to "localhost": [('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify failed')]
ERROR: no successful connection made


2. SU to root and run lmishell command:

]$ su
Password: 
[root@localhost rdoty]# lmi hwinfo
ERROR: invocation failed for host "https://localhost": (1, u'CIM_ERR_FAILED: File "libComputerSystemProvider.so" was not found for provider module "ComputerSystemModule".')
There was 1 error:
host https://localhost
    CIM_ERR_FAILED: File "libComputerSystemProvider.so" was not found for provider module "ComputerSystemModule".: 


3. Attempt to configure self-signed certificate using instructions from www.openlmi.org/PegasusSSL:

$ cp /etc/Pegasus/server.pem /etc/pki-ca-trust/source/anchors
cp: cannot stat ‘/etc/Pegasus/server.pem’: Permission denied
[rdoty@localhost ~]$ su
Password: 
[root@localhost rdoty]# cp /etc/Pegasus/server.pem /etc/pki-ca-trust/source/anchors
cp: cannot create regular file ‘/etc/pki-ca-trust/source/anchors’: No such file or directory
Comment 1 Russell Doty 2013-11-19 18:43:52 EST
Also fails when using --noverify option and su:

# lmi --noverify hwinfo
ERROR: invocation failed for host "https://localhost": (1, u'CIM_ERR_FAILED: File "libComputerSystemProvider.so" was not found for provider module "ComputerSystemModule".')
There was 1 error:
host https://localhost

However, works when logged in as normal user and using noverify:

# lmi --noverify hwinfo
ERROR: invocation failed for host "https://localhost": (1, u'CIM_ERR_FAILED: File "libComputerSystemProvider.so" was not found for provider module "ComputerSystemModule".')
There was 1 error:
host https://localhost


That is, lmishell worked - the hwinfo command failed. Using "partition-table show" didn't return anything; no errors and no output, just returned ready for the next lmi command.
Comment 2 Stephen Gallagher 2013-11-19 20:47:54 EST
(In reply to Russell Doty from comment #0)
> Description of problem:
> 
> Problems using lmishell as a local client (lmi client and server running on
> the same system).


To be clear, 'lmishell' and 'lmi' are different commands. They use the same libraries under the hood, though.

> 
> 1. Attempting to use lmishell from user account:
> 
> $ lmi hwinfo
> username: root
> password: 
> ERROR: failed to make a connection to "localhost": [('SSL routines',
> 'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify failed')]
> ERROR: no successful connection made
> 

This is a normal SSL verification failure. Following the SSL guidelines should deal with this properly. I'll comment on this further in a different reply.


> 
> 2. SU to root and run lmishell command:
> 
> ]$ su
> Password: 
> [root@localhost rdoty]# lmi hwinfo
> ERROR: invocation failed for host "https://localhost": (1, u'CIM_ERR_FAILED:
> File "libComputerSystemProvider.so" was not found for provider module
> "ComputerSystemModule".')
> There was 1 error:
> host https://localhost
>     CIM_ERR_FAILED: File "libComputerSystemProvider.so" was not found for
> provider module "ComputerSystemModule".: 
> 


This shouldn't be possible unless you maybe hit an SELinux issue. Were you running in Enforcing mode? (The missing file is part of the tog-pegasus-libs package and therefore must be installed on your system if Pegasus started). This probably warrants a separate BZ.


> 
> 3. Attempt to configure self-signed certificate using instructions from
> www.openlmi.org/PegasusSSL:
> 
> $ cp /etc/Pegasus/server.pem /etc/pki-ca-trust/source/anchors
> cp: cannot stat ‘/etc/Pegasus/server.pem’: Permission denied

Yes, the certificate file is accessible to root only (for obvious reasons)


> [rdoty@localhost ~]$ su
> Password: 
> [root@localhost rdoty]# cp /etc/Pegasus/server.pem
> /etc/pki-ca-trust/source/anchors
> cp: cannot create regular file ‘/etc/pki-ca-trust/source/anchors’: No such
> file or directory

You have a typo here. As written on http://www.openlmi.org/PegasusSSL, this needs to be /etc/pki/ca-trust not /etc/pki-ca-trust (note the substitution of a slash for a hyphen).
Comment 3 Stephen Gallagher 2013-11-19 20:55:54 EST
In order to deal with the local-system, self-signed certificate case, we might want to consider automatically storing the self-signed certificate in the local trust-store for the machine when generating it. I'm CCing Florian Weimer to check my logic on this, in case I'm missing an attack vector.


When Pegasus is installed via RPM, there is a script run that checks whether the server.pem and friends exist. If they do not, it will generate a self-signed certificate and place them in /etc/Pegasus for us. My suggestion is that we may also want to take advantage of the new shared certificate store feature in Fedora and do:

[root@localhost sgallagh]# cp /etc/Pegasus/server.pem \
                           /etc/pki/ca-trust/source/anchors
[root@localhost sgallagh]# /usr/bin/update-ca-trust extract


The effect here would be that on this machine, we would treat this particular self-signed certificate (generated here) as trusted for further operations. I don't *think* this creates additional security exposure, since the private key is kept local to the system and accessible only to root, but I'd like to hear what Florian has to say on the matter.

Users attempting to perform local administration of the machine through the OpenLMI interface would therefore not be required to manage those certificates themselves.
Comment 4 Florian Weimer 2013-11-20 05:07:57 EST
(In reply to Stephen Gallagher from comment #3)
> [root@localhost sgallagh]# cp /etc/Pegasus/server.pem \
>                            /etc/pki/ca-trust/source/anchors
> [root@localhost sgallagh]# /usr/bin/update-ca-trust extract

On my RHEL 7 system, /etc/Pegasus/server.pem is a X.509v1 certificate (see "openssl x509 -in server.pem -noout -text").  Such certificates don't have extensions, and it is therefore impossible to tell CA certificates and end-entity certificates apart.  As a result, anyone who can read the private key for this certificate could run a rogue CA which is trusted by the local system.

If you fix this and generate a self-signed X.509v3 certificate with a basicConstraints = CA: FALSE extension, installing the certificate in the system certificate store is probably okay.

However, the certificate will still be useful for impersonating other services on the device, like a local PostgreSQL server.  This is a general problem with using X.509 certificates for different services on the same host, so you probably don't have to worry about it too much.
Comment 5 Russell Doty 2013-11-20 21:59:06 EST
I did a fresh install of F20 and tried configuring the certificate. This time everything appeared to work correctly on copying the Pegasus certificate and extracting it.

However, lmishell is still having trouble with the certificate. See BZ 1032849 for details.
Comment 6 Peter Hatina 2013-12-10 06:57:33 EST
Problems described above are related to either proper certificate configuration or SELinux, not openlmi-tools. Closing...

Note You need to log in before you can comment on or make changes to this bug.