Created an attachment (id=1051) [details]
Diff file for globus-job-manager-script.in

Should work on either globus-job-manager-script.in pre-install or on
globus-job-manager-script.pl post-install. Diff is against the 4.0.3 version of
globus-job-manager-script.

This looks cool, thanks. For now we can't commit this to the globus_4_0_branch
code since our current policy is to commit only bug fixes there. That may
change, but for now that's the way it is. So it'd be great if you could also
come up with a patch for the code in HEAD.

I'd recommdend doing it slightly differently, though. In HEAD the Java adapter
interface has been separated out and made more generic. In the interface there
is a preSubmit method that you could use to run an "authorize" command (would
need to be added) in the perl adapter.

You could then add a configuration option to the adapter setup script
specifying the authorization Perl module to use (via automake substitutions of
the .in file). Lastly, this would allow you to provide a GPT package with your
particular authorization Perl module, making the entire mechanism much more
customizable.

If you get stuck, feel free to discuss this on gram-dev since this is a
development discussion.

Created an attachment (id=1052) [details]
more robudy diff file for globus-job-manager-script.pl

This is a more robust diff file designed to be used with patch -p0. It modifies
the globus-job-manager-script.pl file. It is based off the current CVS HEAD
version of the file, but it will also correctly patch the 4.0.3 (and probably
other) versions.

This is not a change to the solution, just a better patch file.

Alain Roy pointed out to me that it looks like this is subject to user injected
badness.  We're running a system() command based on the user's RSL-input
executable and arguments.  Could the user be using characters like pipes and
semicolons in RSL arguments to trick the filter command into saying "yes" when
it shouldn't?

I agree. The system() call should be passed an array of arguments to prevent
shell processing of the arguments.

Until we either have an updated patch that is free of injection badness, or
we're convinced that there isn't injection badness, I recommend that neither
TeraGrid or VDT use this patch. 

Created an attachment (id=1067) [details]
Updated patch to address any injection concerns

This patch passes arguments to system() via a list, which prevents perl from
using a shell to interpret the parameters.

I'm not convinced this was a problem, as the (old) patch escaped any quotation
marks in the command string before passing it to the filter.  Still, Von's
suggestion of using perl's system() call in list format guarantees that the
shell hasn't interpreted any special characters.

The drawback to this approach is that the filter command has to be spliced into
chunks, but I can't see this being a problem in most (if any) cases.

Alain - have you had a chance to evaluate the revamped patch? Does it address
your concerns?

Subject: Re:  Command filtering in globus-job-manager-script


>Alain - have you had a chance to evaluate the revamped patch? Does it address
>your concerns?

Yes, it addresses my security concerns.

I'm not convinced that it's useful by itself. The exercise of writing 
a filter that works well has been left to the reader, and it seems 
difficult to do correctly. That said, I don't object.

Thanks,
-alain

Joe,

Please apply this patch to both the 4 0 branch and the trunk.

Thanks,
Stu

Has this patch been applied?  We're using it in TG to restrict community
accounts via the community shell
(http://security.ncsa.uiuc.edu/research/commaccts/).

Moving this to the LRMA project

Committed to 4.2 branch and trunk.