This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Proposal for PR 13128
- From: Dave Brolley <brolley at redhat dot com>
- To: systemtap at sourceware dot org
- Date: Tue, 27 Sep 2011 12:20:17 -0400
- Subject: 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