This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
security for systemtap compiler server
- From: "Frank Ch. Eigler" <fche at redhat dot com>
- To: systemtap at sources dot redhat dot com
- Cc: Steven Grubb <sgrubb at redhat dot com>
- Date: Mon, 9 Jun 2008 18:31:00 -0400
- Subject: security for systemtap compiler server
Hi -
(... oops, as I was saying ...)
Dave Brolley's prototype work for a networked systemtap compile server
is intended to serve two purposes.
First, it aims to reduce the installation footprint on a given
deployment machine, so that systemtap users can defer work to a single
centralized compiler / kernel-devel / debuginfo toolchain on the
network rather than on every machine that needs probing.
Second, it is part of enabling unprivileged users to run systemtap
scripts that are severely restricted (no kernel probes; only probes on
one's own processes; that sort of thing). (Allowing an unprivileged
user to build his own kernel modules via gcc etc., opens up too many
possibilities for subversion of the constraints.)
Both these parts are tantamount to the local machine's sysadmin
declaring that she trusts a particular remote service to build correct
systemtap modules, and is willing to permit running them (via the
local setuid "staprun" launcher). The remote service must of course
distrust any data sent by the client, and emit code to verify anything
relevant (uid / stapdev group membership, versions/buildids).
How to identify the trusted remote service? One natural way is via a
keypair as in ssh or gpg: have the compile server sign its output
module with a private key; let the (setuid) staprun check the
signature against a sysadmin-approved list in a file like
/etc/systemtap/authorized_keys. (openssl is probably the right
toolkit for this stuff.)
At the minimum, this should prevent an ordinary unauthorized user from
just starting up his own compile server and fool a system into running
its modules. An insecure network would benefit from encrypted data
transfer between client & server (as in stunnel). I haven't thought
much about other threats.
Is all this making sense so far?
- FChE