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]

Systemtap Client/server Certificate Management and Usage Improvements


Hi,

Some internal discussion among us here at Red Hat has led to some ideas for improvement in the management of client/server certificates and thus the ease of use of the client/server. The attached document outlines the details. As is usually the case with detailed designs, it may seem complicated at first, but here is the big picture summary:

1) Client/server certificate databases are no longer generated at build time and are no longer installed

2) One may now start a server simply by using 'stap-start-server'

3) If no server certificate is found by the server in order to identify itself, it will create one automatically. It will also automatically add this certificate to a local client-side certificate database for the user who started the server. Thus the server may be used immediately by that user with no further action required.

4) The user who started the server can use it locally simply by using 'stap-client <normal stap args>'

5) Privileged (EUID=0) users can bless a server for general use by adding its certificate to a global
certificate database on the client using 'stap-add-server-cert <certfile> <dirname>'. The directory
<dirname/client> will be created and initialized, if necessary, and the server's certificate will be added.


6) Checks and balances will be in place to safeguard certificate databases from unauthorized access and to prevent unauthorized users from blessing servers for general use.

Changes 1 through 5 above are already committed at the head of our git source tree

Please read the attached document and, as always, please respond with comments, concerns or problems. Once this design settles I can start adding this information to the User's Guide.

Thanks,
Dave
Overview
========
The use of SSL for wire level security and signing/verification of the
server's response has now been implemented in the systemtap client/server. The
security of the system depends on the proper management of server certificates
and public/private key pairs with which they are signed and verified.

Here is a description of a proposed implementation which was inspired by
recent discussions on Red Hat's internal IRC channel. Please respond with
problems, concerns and ideas for improvement. Much of this is already
implemented in the latest git sources.

Familiarity with basic SSL server authentication and operation is assumed.
Please see https://developer.mozilla.org/en/Introduction_to_SSL for
information.

To summarize, each systemtap server must have a certificate which it presents
to the client in order to authenticate itself and also for signing the
modules it creates. Each client authenticates a potential server's
certificate against its own database of valid certificates. The discussion
below outlines the creation, management and use of these certificates.

Goals
=====
These are the goals of the implementation.

Trust Goals
-----------
A server must only be trusted if it is an actual systemtap server running on
a trusted host. Such trust can not be determined automatically without a
trusted certificate authority issuing systemtap server certificates. This is
not practical in everyday use and so clients must authenticate servers
against their own databases of trusted server certificates. In this context,
establishing a given server as trusted by a given client (i.e. "blessing"
a server) means manually adding that server's certificate and public key to the
client's database of trusted servers.

The authority of a user to establish the trustworthiness of a given server
for a given client therefore must depend the privilege level of the user and
on how the server will be used by the users of that client.

1) Unprivileged users must not be allowed to "bless" a server on any host
   (including localhost) for use by any user except themselves. Allowing them to
   "bless" a server for use by others would allow an unprivileged user to
   establish a proxy server and to potentially collect or eavesdrop on
   information from other users.

   Allowing an unprivileged user to "bless" a server for their own use is
   relatively safer since the information being passed is their own. It is also
   useful for the unprivileged systemtap user who wishes to run 'make check'
   against a transient server (started and stopped by the systemtap testsuite
   harness).

2) Similarly, members of stapdev and stapusr must not be allowed to "bless" a
   server on any host (including localhost) for use by any user except
   themselves. Allowing these users to "bless" a server for their own use is
   useful for the systemtap user who wishes to run 'make installcheck'
   against a transient server (started and stopped by the systemtap testsuite
   harness).

3) There must be some privilege level which allows a user to "bless" a server on
   any host for use by any user. Otherwise no server could ever be "blessed" for
   general use. This capability must be limited to users with root authority
   (EUID=0) on the client host.

4) In the future, unprivileged users should be able to load a module generated
   by servers "blessed" by privileged users. This will be a separate level of
   authority similar to membership in the groups stapdev or stapusr. As such,
   unprivileged users must not be alowed to "bless" a server for this purpose,
   even for themselves. Allowing this would give unprivileged users the ability
   to grant themselves and others permission to load a module.

5) The management of certificates and key pairs should be as automatic as
   possible and the "blessing" of servers for common purposes should be as
   automatic as possible.

Usage Goals
-----------
1) Any user can run stap from phase 1 through 4 inclusive (-p1 through -p4), so
   any user should be able to interface with a trusted systemtap server for
   requests limited to these phases. The server need not be compatible with
   the platform of the client.

2) Currently, only privileged users (root or a member of stapdev or stapusr) can
   load a systemtap module (phase 5). The module must have been generated by
   stap on the local host or on a compatible host. Similarly, privileged users
   should be able to interface with a trusted and compatible systemtap server
    and load the resulting module.

3) In the future (or already?), unprivileged users will be able to load modules
   probing user-space code and, similarly, unprivileged users should then be
   able to interface with a trusted and compatible systemtap server and load the
   resulting module.

4) In the future, unprivileged users should be able to load a module generated
   by servers "blessed" by privileged users. This will be a separate level of
   authority similar to membership in the groups stapdev or stapusr.

Implementation
==============
The following proposed implementation is intended to accomplish the goals
above.

Server Certificates
-------------------
Each server certificate represents a running systemtap server and thus, it
makes sense that each running server should automatically create its own
certificate and public/private key pair if they are not provided.
Automatic creation ensures that the certificate/keys are properly created with
the proper access restrictions.

When a systemtap server is started, it looks for an existing certificate/key
database to use and, if found, uses the certificate and key from that database
to identify itself. The database may not have been automatically created by a
systemtap server or by systemtap tools (see below) so, the database is checked
to ensure the proper access restrictions are in place before it is used.

The first database in the following sequence which is found is used:

1) a database specified on the server's command line.

2) a database local to the user starting the server.

   For unprivileged users, the database is in the directory

     /home/<user>/.systemtap/ssl/server

   For root (EUID=0) users, the database is in the directory

     $(prefix)/etc/systemtap/ssl/server

   where $(prefix) is the prefix used to install systemtap.

If a database is not found, then the server creates its own local database,
certificate and public/private key pair in one of the locations described in
2) above and uses it.

Any user can also manually create a server certificate and key database using
the command

	stap-gen-server-cert <dirname>

A server database with the properties described above will be generated in
<dirname>/server.

o The local server database is writeable only by the user who started the
  server.

o The local server certificate is writeable only by the user who started the
  server.

o The local server certificate is readable by all.

Client Certificates
-------------------
When a systemtap server creates a certificate and key database to be used to
identify itself, it also creates a database containing the corresponding
certificate and public key to be used by a client in order to authenticate that
server. Once again, automatic generation ensures that the certificate and key
are generated correctly and with the correct access restritions.

The client certificate/key database is created along side the server's database
in one of the following locations.

   For unprivileged users, the database is in the directory

     /home/<user>/.systemtap/ssl/client

   For root (EUID=0) users, the database is in the directory

     $(prefix)/etc/systemtap/ssl/client

   where $(prefix) is the prefix used to install systemtap.

Any user can also manually create a client certificate and key database and/or
add a server's certificate to an existing client database using the command

	stap-add-server-cert <certfile> <dirname>

This adds the given certificate to the client database in <dirname>/client,
thus "blessing" that server for clients using that database. If the database
and/or the directory do not already exist, they will be created.

o The local client database is writeable only by the user who created it (i.e.
  started the server).

o The local client database is readable by all users.

When a systemtap client is started, it looks for existing certificate/key
databases to use and, if found, uses the certificates and keys from those
databases to authenticate potential servers. The databases may not have been
automatically created by a systemtap server or by systemtap tools so, the
databases are checked to ensure the proper access restrictions are in place
before they are used.

All of the databases in the following sequence are searched in the order
specified below when attempting to authenticate a server.

1) databases specified on the client's command line in the order specified.

2) a database local to the user starting the client. The location of this
   database is the same location as the client database automatically created by
   a server started by the same user (see above).

3) For unprivileged users, $(prefix)/etc/systemtap/ssl/client. This
   is the same location as the client database automatically created for root
   users by systemtap servers. This is the database which "blesses" servers for
   use by all users on the client host.

If a database is not found then the client cannot authenticate any potential
servers and cannot continue.

Authentication
--------------
1) When a client initiates a connection with a potential server, the normal
   SSL handshake protocol is performed. The server presents the signed
   certificate with which it was provided, found or generated. The client
   verifies the certificate against certificates it finds in its specified,
   local and public certificate databases.

2) The server digitally signs any resulting module using its certificate and
   private key. The client will use its copy of the certificate and the server's
   public key to verify the signature. Successful verification of a module
   signed by a "blessed" server will consitute permission for the client to
   load the module regardless of the user's privilege level. This will be
   checked by staprun. For this purpose, staprun will only search for the
   server's certificate in the global client certificate database. 

Goals Met by the Implementation
===============================
This section demonstrates how the implementation meets the stated goals.

Trust Goals
-----------
1) "Unprivileged users must not be allowed to "bless" a server on any host
    (including localhost) for use by any user except themselves."

  - Unprivileged users cannot write to the local client databases of other
    users, nor the local client database of the root user. Thus an unprivileged
    user cannot "bless" a server on behalf of another user. Nor can any user
    tamper with the client database of another user.

  - The generated server certificates are readable by all users, so
    unprivileged users can add a server certificate to their own client
     databases using stap-add-server-cert and can therefore "bless" servers
     for their own use.

  - Access permissions of the client database are checked by the client before
    a database is used in order to enforce the above restrictions.

2) "Members of stapdev and stapusr must not be allowed to "bless" a
    server on any host (including localhost) for use by any user except
    themselves."

  - Members of these groups have no special access to the client
    certificate/key databases of other users and so they have no authority in
    this regard beyond that of unprivileged users.

3) "There must be some privilege level which allows a user to "bless" a server
   on any host for use by any user.

  - Only root level users (EUID=0) have write access to
    $(prefix)/etc/systemtap/ssl/client which is both the global client
    database and the local client database for root users. Thus, root level
    users can "bless" any server for use by all users by adding that server's
    certificate to this database using stap-add-server-cert.

  - Access permissions of the client database are checked by the client before
    a database is used in order to enforce the above restriction.

4) "In the future, unprivileged users should be able to load modules generated
    by servers "blessed" by privileged users. Unprivileged users must not be
    allowed to "bless" a server for this purpose, even for themselves.

  - only root level users (EUID=0) have write access to
    $(prefix)/etc/systemtap/ssl/client which is the global client
    database.

   - staprun will only search the global client database for certificates
     to verify the signature on the module, thus only root level users
     can "bless" a server for this purpose.

  - Access permissions of the client database are checked by staprun before
    a database is used in order to enforce the above restriction.

5) "The management of certificates and key pairs should be as automatic as
    possible and the "blessing" of servers for common purposes should be as
    automatic as possible."

  - The client database automatically created when a systemtap server is
    started is in the location of the user's local client database. Thus a
    local server started by any user is automatically "blessed" for use by that
    user.

  - The local client database for root users is also the global client
    database for all users. Thus, any local server started by a root user is
    automatically "blessed" for use by all users on that host.

  - Similarly, the modules generated by any local server started by a root 
    user are "blessed" to be loadable by any user.

Usage Goals
-----------
1) "Any user should be able to interface with a trusted systemtap server for
    requests limited to phases 1 through 4. The server need not be compatible
    with the platform of the client."

  - Since no generated module is loaded, then any server "blessed" for a
    a given user can be used for this purpose by that user.

2) "Privileged users should be able to interface with a trusted and compatible
    systemtap server and load the resulting module."

  - As above, any trusted and compatible (checked by stap-client) server can
    be used to generate the module.

  - staprun is used by the client in order to load the module and will enforce
    the restriction on loading.

3) "In the future (or already?), unprivileged users should then be able
    to interface with a trusted and compatible systemtap server and load
    modules which probe user level code."

  - This is conceptually no different than goal 1) with the restriction that
    the module must probe only user level code.

4) "In the future, unprivileged users should be able to load a module generated
    by servers "blessed" by privileged users."

  - The same certificates are used to sign and verify the server's digital
    signature on a module as are used to authenticate the server. Thus a
    module signed by any "blessed" server will be loaded by staprun privided
    the server's certificate is found in the global client certificate database.

  - Unprivileged users do not have write access to this database.

  - Access permissions of the client database are checked by staprun before
    a database is used in order to enforce the above restriction.

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