Re: security for systemtap compiler server

[fche at redhat dot com (Frank Ch. Eigler)]

Masami Hiramatsu <mhiramat@redhat.com> writes:

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

It is *both*.  A sysadmin may want to permit an unprivileged user to
run systemtap scripts, but only if they are built by a trusted
toolchain (so that it will compile in the proper constraints).  Such a
user cannot be build a trustworthy .ko himself -- after all, there is
no proof that any old .ko was even created by systemtap.


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

While ssh could conceivably operate as the wire transport layer, we
still need something above it to (a) bundle any tapsets requested by
the end-user via -Ipath/ flags; (b) invoke the toolchain in a
trustworthy (unmodifiable) manner; (c) cause the resulting module to
be reliably crypto-signed; (d) get back all the results - .c/.ko,
stdout/stderr, exit-rc.  A plain "ssh SERVER stap -p4 ..."  wouldn't
accomplish these.


- FChE