Bug 1032305

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.

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

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.

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

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.

Problems described above are related to either proper certificate configuration or SELinux, not openlmi-tools. Closing...