Network Security for the Systemtap Client/Server

[Dave Brolley]

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