Re: Network Security for the Systemtap Client/Server

[Dave Brolley <brolley at redhat dot com>]

Frank Ch. Eigler wrote:
>   
> > [...]
> > 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).
> >     
>
> The first of those threats is not so bad, considering module signing.
> The second is not that bad.  But a third, modification of the script
> en route to the server, is bad, and justifies efforts to secure the
> wire.
>   
If I understand correctly, the only way to ensure that the script has 
not been modified on route is to have the client sign it with its own 
certificate and private key. This can be easily done using the same 
techniques used by the server to sign its response. This, in my opinion 
is a separate issue from the two issues mentioned above.
> > [...]
> > 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 [...] It would then call stap, passing it the name of
> >    the archive. stap would then send it to the server [...]
> >     
>
> It seems clumsy to have to use stap just so that it can do
> stunnel-like data transfer.  Is there a perl binding to NSS, so that a
> rewritten stap-client could use it.  Maybe nss_compat_ossl....
>
>
> Or, really, we can buck the fedora trend briefly and go with plain
> openssl (with stunnel and/or perl bindings) until NSS becomes
> similarly functional.
>   
Agreed. I mentioned this in the notes at the end of the proposal.
> > [...]
> > 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.
> >     
>
> An extra complication here is that module signing is mainly there to
> help enable future systemtap use by unprivileged users.  The trusted
> server would impose extra constraints and return a probe module that
> compiles in any additional checks needed.
>
> The signature on such a module needs to be carried through right
> through to staprun - beyond stap-client - since staprun is the setuid
> piece that must ultimately decide whether to load/run a proposed
> module or not.  It needs to perform the signature verification to
> assure the local system(admin) that the possibly unprivileged user who
> ran stap-client did not mess with the resulting module.
>
> (Doing all this via the kernel module-signing code in some kernels
> would not be appropriate, according to its author.)
>   
With appropriate constraints applied by the server to ensure that an 
unprivileged client does not gain permission to load/run a maliciously 
designed module, I agree. Note that stap-client makes use of more than 
just the returned module. Output from stap on the server side is also 
used and this is why I'm proposing that the entire server response be 
signed. stap-client needs to know that no part of the server response 
has been tampered with.

Some possibilities for verification of the module by staprun on the 
client side are:

1) Separately sign the module within the signed server response, which 
seems a bit redundant to me given that the entire server response is 
already signed by the server and verified by the client.

2) Have staprun verify the entire server response again. Again some 
redundancy, but perhaps necessary given that staprun can not afford to 
trust that it was called by a legitimate client.

3) Something else?
>   
> > [...]
> > 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.
> > [...]
> >     
>
> All that must be automatable to death.  The wire protocol part's user
> interface should be no clumsier than, say, svn talking to a https:
> server.
>   
Right. Bear in mind that these are sysadmin tasks performed once for 
each client/server on the network. These tasks are analogous to using 
ssh-keygen to generate key pairs for ssh and adding the public 
identities to each machine one wants to access.
> The module signature verification is a whole separate mechanism.
> There, the sysadmin-approved list of module-signing public keys need
> to be installed into a special place ($etcdir/systemtap/server-keys),
> which staprun would validate against.
>
>   
Yes. I suggest that 'make' and 'make install' generate and install key 
pairs and certificates for development environments and that installing 
the stap-server rpm do the same for production environments. We should 
also create some helper scripts to help sysadmins add the public keys 
and certificates of their trusted servers to client machines properly.

Dave

> - FCHE
>