The fellows here working on galaxy, about ready to release it to prime time, came to me asking about a few sudo commands that they needed. looking into it I came across a discussion (http://osdir.com/ml/galaxy-development-source-control/2011-11/msg00067.html) from last November talking about why this was being done and the security issues.

Because I’m coming at this from the systems side, I’ve got a keen interest in the security aspect of things so I’ve dove into this with hopes of developing what might be a more secure approach. The issues that we have run into center around the sudo approach taken by the three scripts: external_chown_script, drmaa_external_killer.py and drmaa_external_runner.py.

I have read the comments from Nov on galaxy-dev on using sudo but have taken a different approach.

The issue with the external_chown_script is that is does a “sudo chown” and “sudo chgrp” allowing the galaxy id to chown any file on the system, not just ones involved with galaxy, and because this sudo permission is system wide, the permission is not just via the scripts, but extends to any command line with the galaxy id. Also, because the sudo is on “chown”  and not “/bin/chown” there is a potential of PATH manipulation to substitute in a malicious or harmful  “chown”. This is a bad thing™.

The issue with the other two scripts (drmaa_external_runner and drmaa_external_killer) scripts is that the sudo is on the entire script which can be edited after the sudo is setup to contain potentially malicious/harmful code. Also a bad thing™.

But you know all that, and we all know that this is a tricky issue.

1. What I have done is to create a compiled C program, to replace external_chown_script.py. This program is intended to be installed setuid root. I have added checks to ensure that it is used as intended and then do the appropriate changes via the chown(2) system call.  As this is to be installed setuid root, there is no longer a need for a sudo setting on chown(1).

2. The other two scripts, because of the midstream setuid to an arbitrary user need to also be setuid root compiled programs. After toying with some python compilers unsuccessfully, I just coded them in C.

drama_external_killer.py is done, and I’m mostly finished drama_external_runner.py with the exception of parsing the JT_JSON file containing the job definitions.

Because the guys working on the galaxy install haven’t quite got it running, I don’t have an example of a .jt_json file from which I can see samples of the input to map it into drmaa_set_attribute() and drama_set_vector_attribute() calls. Most of the keys are obvious (remoteCommand, outputPath, …) but I don’t know how to map the following

Name – should this be DRMAA_JOB_NAME?

Email – should this be DRMAA_V_EMAIL, and if so why is it a vector?

Project – no idea where to map this

aTdHvAaNnKcSe, I plan on releasing my code, when it hardens, to the galaxy community if there is interest in the setuid approach instead of the sudo approach to job submission/control

__

cheersLance

| Lance Bailey, Systems

| GSC, 100-570 W 7th Ave

| 604-707-5900 x5413

| Vancouver BC, V5Z 4S6 Canada