Re: Network Security for the Systemtap Client/Server

[Dave Brolley <brolley at redhat dot com>]

Frank Ch. Eigler wrote:
> Hi -
>
> On Wed, Nov 05, 2008 at 04:53:25PM -0500, Dave Brolley wrote:
>
>   
> > > > Wire Level Security
> > > >         
> > [...]
> > 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. [...]
> >     
>
> That could well be an overkill.  Standard wire-level security like
> TLS/SSL, without extra explicit signatures, should be sufficient for
> protection against a hostile network.
>   
I'll let you make the call on sufficiency. However while a SSL/TLS 
connection provides server authentication and encryption, I still don't 
believe that it alone protects against tampering. Search for "tampering" 
in the following page:

https://developer.mozilla.org/en/Introduction_to_Public-Key_Cryptography#Internet_Security_Issues
>   
> > [...]
> > 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.
> >     
>
> That's a good point, but that's adequately addressed by wire-level
> security.  It may help to consider the wire-level stuff orthogonal -
> as indeed it is since we can theoretically connect stap-client and
> stap-server with a local unix pipe.
>   
Once again, I believe that if we're worried about tampering, then 
signing is the way to protect against it.
>   
> > 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. [...]
> >     
>
> Yes, but the client (stap-client) cannot be trusted by staprun.
> staprun need only care that the final module is built correctly.
>   
So are you preferring the option above over option 2 (staprun 
re-verifies the entire response)?
> > > [...]
> > > 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.
> >     
>
> I don't see a need yet for client-side *authentication* that might
> necessitate signing keys there, so that leaves only the ssh-keygen
> part.
>
> So, for module-signing purposes, sshd's host key is analogous to
> stap-server's signing key, and ssh's $HOME/.ssh/known_keys (treated
> more like authorized_keys) is analogous to the staprun's approved keys
> list.
>   
We're in agreement here.

Dave