Description of problem: Presently, any Satellite/Spacewalk user with the configuration administrator role code execute code as root on the Satellite/Spacewalk server by putting something like "<%= os.popen('/usr/bin/id').read() %>" in a templated kickstart script or variable. The same can be done in a non-templated script by wrapping the command in #end raw and #raw directives. Cheetah should probably not be invoked as root. Additionally, the following checks should be made to prevent the execution of code on the server: * Refuse to accept templated scripts or variables that include unescaped <%= ... %>, <% ... %>, or #compiler-settings directives. * Prevent the use of the #end raw directive in non-templated scripts (e.g. s/#end/##end raw gobbled #raw end/ the raw scripts before writing out the kickstart template). Version-Release number of selected component (if applicable): n/a
Hi, Jonathan. Ok great. Thank you for that confirmation. Also to quickly confirm, this is limited in scope only to users of the configuration administrator role, correct? I don't have a spacewalk or satellite install handy to quickly test this, and I suspect it will be tomorrow before this gets looked at.
I am not aware of any way for users that do not have the configuration administrator role modify any kickstart scripts. So yes, I believe that to be true.
Given the multiple organizations feature of Satellite, it is possible for users who aren't trusted by the Satellite administrators to have the configuration role. We have that issue at UA, where other departments and ancillary groups have access to their own kickstart configs, but don't (or at least, shouldn't) have access to the Satellite itself.
05:41pm <@akesling> alright, so here's the plan (as per a discussion with shenson a moment ago): set up a subprocess, which will run as a non-privileged user, once in the process lower set ulimit such that it won't be able to spawn any processes... 05:42pm <@akesling> also go ahead and read in all snippets required (the only thing we need on disk), and then reduce the allowable file descriptors as low as possible (can we set that to 0? Will it just prevent the process from creating _new_ descriptors, or close open ones?), and _then_ execute the Cheetah code.
Created attachment 434056 [details] patch to disable execution of python code in Cheetah templates I'm attaching a patch for cobbler that should configure Cheetah to not allow python code to be embedded. Is there a functional requirement that is preventing us from doing something like this? I think that configuring cobbler so that it can be run as cobbler:cobbler instead of requiring root privileges would go a long way toward mitigating security risks by itself. Is it reasonable to disable PSP execution to address this issue, and pursue executing cobbler as a non-privileged user as a separate enhancement.
For what is worthy regarding addressing this deficiency in Spacewalk systems management tool -- the relevant flaw needs to be addressed in the versions of the cobbler package, as shipped with Fedora release of 12 and 13. Particular tracker bug for cobbler package in Fedora is here: [1] https://bugzilla.redhat.com/show_bug.cgi?id=607662#c11 So closing this bug.