This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Proposal for PR 13128


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]