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]

Re: Network Security for the Systemtap Client/Server


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.


> [...]
> 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.


> 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.


> >[...]
> >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.


- FChE


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