Re: Proposal for PR 13128

[Josh Stone <jistone at redhat dot 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