[torqueusers] Security Vulnerability in Torque
dgolden at cp.dias.ie
Fri Oct 20 17:45:30 MDT 2006
On 2006-10-20 16:06:42 -0600, Garrick Staples wrote:
> > Hmmm. Are --disable-spool torque builds still vulnerable ?
> I wouldn't think so, but I haven't confirmed that.
okay, well, here's another eyeball on it, though it's
past midnight here, someone-else-again might want to confirm!:
--disable-spool builds shouldn't be vulnerable to this problem,
"keeping" is always forced to 1 in the --disable-spool case in
start_exec.c/std_file_name(), and the system thus always set[eg]ids
to the user before opening the spool files in the user's home dir
in start_exec.c/open_std_file() , and always forks to the
user in requests.c/req_cpyfile() before copying back the spool files ?
So, well, you could still sequence-predict, but
it shouldn't get you anywhere in the --disable-spool case.
re style of fix:
* I guess one part of the fix might be to sete[ug]id before open
even in the keeping=0 case... I don't see why one wouldn't? (except of
course on systems that don't support sete[ug]id at all...). Does
that in fact eliminate any problem?
* sequence-prediction: I'm not sure about the whole randomising
the name thing. - Yeah, it'll be less predictable, so in principle
it's a good thing from a security perspective: But I know that skins
have been saved here a couple of times now in the face of system failure
by the predictability of such names, for partial job output recovery.
* while it's likely good to check if the file exists, I'm not so
sure about "simply removing" the file if it already exists (as
suggested somewhere) - might be much better to signal an error
and abort - there's some funny business going on in that case...
or is there? - what does the mom do for rerun, suspended and
checkpointed jobs, and after a mom polling restart is the goal also to
reopen the same files? I suspect yes, so you might want a predictable name
, or at least persistent tracking of an unpredictable one (as Luis
suggests)) - but that's still going to complicate rescue of
partial job outputs in the face of system failure, unless that
persistent tracking table is easily human-readable (perhaps only
by privileged users...)
More information about the torqueusers