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, Dave -

Thanks for your writeup.


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


> Authentication of clients is also possible although may not be
> necessary.  [...]

Agreed.


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



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


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


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]