Proposal for PR 13128

[Dave Brolley]

Additional issue:

Currently, members of stapdev can load unsigned modules. Unless we want 
to change this, we'll need a new group. I'm open to suggestions for an 
appropriate name.

Dave

On 09/27/2011 12:20 PM, Dave Brolley wrote:
> Hi,
>
> With regard to http://sourceware.org/bugzilla/show_bug.cgi?id=13128
>
> The idea is to implement a privilege level between the current stapusr 
> (full --unprivileged mode) and stapdev (full access) which would allow 
> the use of all functionality except custom embedded C code.
>
> Expanding the stap command line and implementing the necessary 
> constraint checking is the easy part and would, for the most part, 
> reuse existing code which implements the current stapusr 
> --unprivileged mode. For the command line, I propose adding an 
> argument to the existing --unprivileged option as follows:
>
> --unprivileged[=stapusr|stapdev]
>
> Specifying no argument or 'stapusr' would specify the existing stapusr 
> --unprivileged mode. Specifying 'stapdev' would specify the new 
> stapdev privilege restrictions. Alternate suggestions for this are 
> welcome.
>
> Things get interesting when we consider the security implications. 
> Once again, for the most part, we can reuse the existing mechanism in 
> place for stapusr --unprivileged mode. The current mechanism is:
>
>   1. The stap client submits the user's script to a trusted
>      compile-server for compilation.
>   2. The compile-server checks that the script meets the required
>      constraints.
>   3. If so, the compile-server signs the resulting module.
>   4. On the client-side, staprun verifies the module's signature
>      against the server's certificate, ensuring that it was approved by
>      the server and has not been altered since it was signed.
>
> We can use the same mechanism up to step 3 for the new privilege 
> level. At step 4, staprun will still verify the module's signature, 
> however staprun now also needs to know for which privilege level the 
> module was approved. If the module was approved for 
> --unprivileged=stapusr, then it's business as usual and the module can 
> be loaded for any user who is root, or a member of stapusr. If the 
> module was approved for --unprivileged=stapdev, then the user must be 
> root, or a member of stapusr and stapdev.
>
> Since staprun can be used to load previously compiled modules, the 
> information must be available to staprun alone and cannot be passed as 
> part of the compile/load process of the client.
>
> I considered having the server sign the module using a different 
> certificate for each privilege level. That way the client would verify 
> the module against different client-side certificate databases in 
> order to determine the privilege level. However, this lead to many 
> complications in the management of the required certificates including 
> the possibility that a sysadmin could mistakenly add the same 
> certificate to both databases, which would circumvent the verification 
> process for stapusr.
>
> The solution that I'm proposing is to have stap 'mark' the module with 
> the privilege level that it was compiled for. This would be done by 
> adding a special section to the module itself containing the data 
> indicating the privilege level. The data itself could be a string or a 
> numeric code. The key point is that this mark would be added before 
> the module is signed and would be part of the signed data. Thus, when 
> staprun verifies the module's signature, it knows that the mark has 
> not been altered. staprun can then use the mark to correctly enforce 
> the correct privilege level before loading the module. Legacy modules 
> which have been signed, but do not contain the mark will be assumed to 
> have the current stapusr --unprivileged privileged level.
>
> Comments, questions and concerns are, as always, welcome and encouraged.
>
> Dave