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


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



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