This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Network Security for the Systemtap Client/Server
- From: Dave Brolley <brolley at redhat dot com>
- To: systemtap <systemtap at sources dot redhat dot com>
- Date: Thu, 23 Oct 2008 17:12:14 -0400
- Subject: Network Security for the Systemtap Client/Server
Hi,
See the attached file...
Dave
Here is a proposal for security for the systemtap client and server. Please
poke holes in it and correct me where I am mistaken or where I have missed
something. As always, ideas, suggestions, corrections and concerns are
encouraged!
Toolkit
-------
Network Security Services (NSS), http://www.mozilla.org/projects/security/nss,
provides command line tools as well as an API for providing SSL services
such as encrypted network connections, client/server authentication and
for object signing.
openSSL, http://www.openssl.org, also provides a toolkit and API for these
services.
It would appear that the library/tools of choice for cryptography, going
forward on Fedora and RHEL is Network Security Services (NSS). This is mainly
due to superior certification history and completeness. See
http://fedoraproject.org/wiki/CryptoConsolidation
http://fedoraproject.org/wiki/CryptoConsolidationEval
Wire Level Security
-------------------
Wire level security is necessary to prevent spoofing (impersonation) of
systemtap servers as well as eavesdropping on the data stream
between the client and server (man in the middle).
Authentication of clients is also possible although may not be necessary.
The systemtap server is simply compiling the provided scripts and is not
returning any information which could not be obtained using the resources
used to perform the compilation. These resources (kernel version and
debuginfo, systemtap itself) are already widely available.
**** Comments? concerns? suggestions? ***
SSL network connections, as provided by NSS, provide this level of security.
I have identified two possibilities for implementation:
1) Use stunnel to provide SSL connections between the existing stap-client and
stap-server(d) scripts. stunnel is easy to use and would require few, if any,
changes to the existing scripts. On the downside, stunnel is currently based
on openSSL and uses the .pem file format for certificates and keys, which
differs from the password protected key/certificate databases used by NSS.
stunnel has been identified as a tool to be converted to use NSS
http://fedoraproject.org/wiki/CryptoConsolidation#Packages_to_NSS-enable
but there is no indication of when or if this will happen.
2) Use the NSS C language API for SSL from within stap to communicate with
the server. The stap-client script would still create the request as a
directory tree as it does now and would still package the request into an
archive (currently uses tar). It would then call stap, passing it the name of
the archive. stap would then send it to the server and receive the result
archive using an NSS SSL connection. The stap-client would then unpack the
archive and process it as it does today.
This approach has the advantages that it uses NSS immediately. This means we
need not rely on migration of stunnel to NSS actually ocurring. We can also
use the same client/server certificates for both signing and for secure
connections.
**** Is it more secure to use separate certificates for each? ****
3) Something else? Suggestions?
Module Signing
--------------
It is desirable that the client be able to verify that the data returned from
the server has not been tampered with. This can be accomplished by digitally
signing the data. Once again NSS provides facilities for signing and
verifying arbitrary data.
The NSS tool 'signtool' is able to sign a directory tree using a certificate
and keypair which it can also generate. Certificates and key pairs can also
be generated using the NSS tool 'certutil'. signtool signs the directory and
compresses it (using the zip utility) into a single file called a .jar file.
The .jar file can then be verified also using signtool.
Since the stap server's response to the client is a directory tree, it can be
signed in its entirety. The resulting .jar file could then be sent back to the
client, allowing the client to ensure that the entire response has not been
tampered with.
Administration
--------------
Here is how a sysadmin would administer a trusted systemap server. All
commands below must be executed as the userid which will run the server.
1) The sysadmin creates an NSS certificate/key database using the commands
touch <passwordfile>
chmod 600 <passwordfile>
echo "password" > <passwordfile>
mkdir -p <dirname>
certutil -N -d <dirname> -f <passwordfile>
This creates an empty certificate/key database in the directory named by
<dirname>. The password needed to access the private key(s) in the database
is obtained from <passwordfile>, which is a plain text file, so care must
be taken to prevent unauthorized access to this file. Use of a password
file will allow the systemtap server to access the private key(s) in the
database without being prompted.
2) The sysadmin then creates a certificate and its associated public/private
key pair and adds them to the database for the server using
signtool -G <certname> -d <dirname> -f <passwordfile>
where <certname> is a nickname used to refer to the certificate/keys in the
database. The sysadmin will be prompted for all information needed to
create the certificate.
The certificate created is a self-signed certificate (since it was not
issued by a certificate authority) and is also a signing certificate (it
can be used by NSS tools to sign arbitrary data). Because it is self-signed,
each client must use a local copy in order to verify an SSL connection
with a server or the signed data (see below).
3) The 'signtool -G' command also creates the file x509.cacert which has
the MIME-type application/x-x509-ca-cert. This file can be installed
in the certificate/key database of each client in order to allow each
client to establish secure connections with the server and to verify the
integrity of the server response. This is done on each client host by
copying the file to the client host and then:
mkdir -p <dirname>
certutil -A -n <certname> -d <dirname> -i x509.cacert -t "P,P,P"
This creates an NSS certificate/key database in <dirname> and adds a copy
of the server's certificate and pulic key. The certificates of multiple
servers can be added to the database. No password is required, since the
database contains only the certificates and public keys of each server.
This database must be accessible by all users who will be running the
client on the client host. In addition to, or instead of a common
certificate/key database, each user could have their own.
Implementation
--------------
Once the certificate databases have been set up on the client server, they would
be used as follows:
1) The client would use NSS services to establish a secure SSL connection with
the server. During the SSL handshake, the client would verify the certificate
presented by the server against its own local copy. This is necessary since
the server's certificate is self-signed and thus can not be verified on its
own (i.e. it is not signed by a recognized certificate authority).
2) The server would sign its response tree using its own certificate and
private key as follows:
signtool -Z <response-tree>.jar -d <dirname> -k <certname> -f <passwordfile> <response-tree>
This generates the signed archive '<reponse-tree>.jar' which would be sent
back to the client over the secure connection.
3) The client would verify the response using its own copy of the server's
certificate and public key as follows:
signtool -d <dirname> -v <response-tree>.jar
Note that no password is required since only the server's certificate and
public key are being used.
4) Once verified, the client can unpack the response using the unzip utility.
Notes
-----
o The use of self-signed certificates requires that each client maintain
a database of the certificates and public keys of each server to be used. It
is possible for a sysadmin to set up an internal certificate authority and to
use the certificate and private key of that authority to sign the certificates
of each server. The clients would then need only the certificate and public
key of the internal certificate authority in order to verify any server on the
network.
signtool has the ability to verify such certificate authority chains.
A combination of authorized servers and ad-hoc (self-signed) servers
is also possible. The verification process would then be to attempt
verification against the certificate authority certificate and then against
local copies of ad-hoc server certificates.
o Although stunnel uses a different method of storing certificates and keys,
it is possible to construct the required .pem files using the output of
signtool and certutil. It is also possible to construct certificate authority
chains for use by stunnel. Initially it is likely that stunnel will be used
for secure SSL connections bewteen the client and server.
o The above model does not address authentication of clients by servers. At
this point, I do not believe it is necessary (problems and concerns please!).
However, client authentication is an optional part of the SSL handshake
and the creation and maintenance of client certificates and keys is
analogous to those of the server.
o One of the goals of the Fedora Crypto Consolidation Project
http://fedoraproject.org/wiki/CryptoConsolidation
is that all applications on a system access a common certification/key
database. Using NSS, this will be possible once such a thing exists. However,
this would lead to trusting systemtap servers on hosts which have been
potentially entered into the database (i.e. trusted) for other reasons
(e.g. SSL-enabled mail server), which may not be desirable.