Proposal for PR 13128

[Dave Brolley]

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