Re: security for systemtap compiler server

[Roland McGrath <roland at redhat dot com>]

Btw, I gather that NSS is supposed to be the preferred and one true toolkit
for all crypto things now.  But I don't really know anything about it and
surely our needs are normal enough that the security folks with clue will
quickly direct us to exactly what to use in each implementation language
environment.

Two intertwined angles related to security come to mind off hand.

First is securing user from a bogus remote compile server, as well as the
system.  That is, only sending user data (i.e. the script) on a private
channel authenticated as the trusted server.

Second is "live" (session) security vs "batch" security.  Your descriptions
implied some things about this, but didn't make them explicit.

The user's data security is only about the live session security.  You want
to be sure your channel is private and is to a trusted server before you
send it any user data at all.  TLS/SSL alone does this, if used in the
appropriate way (client verifies expected server keys).  I don't know it's
easy to do that with stunnel, but it's surely easy enough with the
facilities to be an SSL client in whatever other environment fancier than
sh (perl, python, C, etc).

I think Frank implied "batch" security, i.e. signed module nuggets a la
gpg-signed files/messages.  I presume this is necessary too, because it
enables so many things we probably want: normal user files for module
caching, minimal privileged staprun separate from the app that talks to the
compile server.

So the "trust vectors" I see are:

1. Normal user trusts session to remote compile server with user's own data,
   that it will complete/fail properly, not produce a gargantuan result, etc.
   (Here "user" means unprivileged user process running stap-client/stap,
   unprivileged apps of same euid that invoked it, person who asked for that.)

2. (reciprocal) server trusts session from remote user to be permitted,
    vs DoS, unavoidable leaks of server config details, etc.

3. Local privileged staprun process trusts artifact based on crypto
   signature and local config of authorized module signing keys.
   i.e. signed module nugget supplied by untrusted/unprivileged user


#2 says paranoid admin might want to have various forms of access control
(ranging from user SSL key ACLs to nothing but "you can firewall it")

If #3 were going to be the only thing ever authenticating a server, then it
could be cobbled together in a scripty way with gpg quite easily.  

For #1, probably anyone who does not care about authenticity also does not
really care about privacy.  Simple cobbling together with stunnel gives us
privacy, but might not give us authenticity, and if it did certainly adds
to the key management headache.  So off hand I suspect that stunnel alone
is not worth bothering with.

If both ends are already shell scripts, then we can cobble something
demo-ready using gpg in about three minutes (and then spend the rest of the
month figuring out what exactly to cobble for the server public key
management on the client).  But for a long-run "real" plan, I tend to think
we'll need enough of something more real in dept #1 that I wouldn't bother
with a gpg hack.

If there will be authentication of a server's key in an SSL session for #1
and also authentication of a server's signed nugget in a minimal local
privilged program for #3, then it sure pays to have the key management
unified.  I'm pretty sure that the proper toolkits like NSS (and its
cousins and wrappers in various languages) make it pretty easy to do simple
batch-style signing and verifying using the same keys that the SSL/TLS
layer uses.


Thanks,
Roland