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] |
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.[...]
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.
Agreed. I mentioned this in the notes at the end of the proposal.
[...]
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.
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.[...]
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.)
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.
[...]
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.
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.
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.
- FCHE
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |