This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]