Re: security for systemtap compiler server

[Masami Hiramatsu <mhiramat at redhat dot com>]

Hi,

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

Indeed, there is no proof.
Hmm, if staprun needs to check whether .ko is genuine or not,
there may be same problem when using pre-compiled module.
In my thought, we might have to introduce 2-way authentication;
 - user/group based authentication for stap/staprun.
 - crypt-sign based authentication for staprun.

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

I think some of them can be accomplished by ssh with some scripts
(not plain ssh :-)). But, yeah, (b) is hard, especially, over network...

Thank you,

-- 
Masami Hiramatsu

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

e-mail: mhiramat@redhat.com