security for systemtap compiler server

[anithra]

Hi Frank,

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.
>
>
>   
>> [...]  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
>   
 From what i understand the security requirements for the 
compiler-server and the stapgui-server(with remote-execution& 
compilation) are similiar, in which case is there anything else that 
prevents us from extending the compiler-server for remote-execution?.

Regards,
Anithra.