Re: security for systemtap compiler server

[Masami Hiramatsu <mhiramat at redhat dot com>]

Hi,

Frank Ch. Eigler wrote:
> 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.

Sure.

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

I think this is also the issue of systemtap itself, not only
compiler server, because it is a run-time privilege issue.

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

IMHO, ssh is better approach, because it becomes the basic function
for remote access now, so we may not need to setup something special
on the server and the client.

I also think if we can use ssh to get compiled module from server,
we don't need special server program (this means we don't need to open
any port for server program). User authentication is also easy.
If you need more sophisticated system, ssh also supports '-s'(subsystem)
option like sftp.(I think it is enough to call a shellscript which
gets parameters, and returns module or result.)


Thanks,

-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: mhiramat@redhat.com