This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Proposal for PR 13128
- From: Josh Stone <jistone at redhat dot com>
- To: Dave Brolley <brolley at redhat dot com>
- Cc: systemtap at sourceware dot org
- Date: Tue, 27 Sep 2011 11:22:43 -0700
- Subject: Re: Proposal for PR 13128
- References: <4E81F7C1.2070708@redhat.com>
On 09/27/2011 09:20 AM, 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.
Superficially, this means no -g allowed. But for this mode to be at all
meaningful, it has to also restrict all the other ways to influence the
kernel code: -I, -R, -r/path, -D, etc. We can audit this again, but I
suspect that the set of disallowed options will need to be the exact
same as the current stapusr mode.
So really, this new mode should have a lot of the restrictions of
stapusr, but relaxed access to probe points and tapset functions.
> 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.
If we had this feature from the start, I might have said stapguru for
unrestricted mode and stapdev for this non-guru mode. But at this
point, I don't think we should alter the meaning of stapdev. Let's have
a new group for the new restrictions.
> 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.
It's not just about previously-compiled modules. Between the trusted
compile-server and the setuid staprun, you have the untrusted client, so
only signed information can be trusted.
> 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.
I agree, better to keep the certificate management as simple as we can.
> 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.
This sounds like a good solution to me. We already have other code
inspecting sections for the module renaming effort, so this isn't too
far off. For the data I suggest just the unprivileged group name, so
staprun can be ignorant of the underlying policy. Just read the group,
check that the user is a member of that group, and proceed.
Josh