Re: [Condor-users] grsecurity tpe and condor standard universe

[Brian Kroth <bpkroth@xxxxxxxx>]

Jaime Frey <jfrey@xxxxxxxxxxx> 2008-05-09 10:35:
> On May 8, 2008, at 11:53 AM, Brian Kroth wrote:
>
>> I'm testing out condor on a Linux machine running with grsecurity/pax
>> patches.  There's a setting that's causing some problems:
>> kernel.grsecurity.tpe_restrict_all = 1
>>
>> From the docs:
>>
>> CONFIG_GRKERNSEC_TPE_ALL:
>>
>> If you say Y here, All non-root users other than the ones in the group
>> specified in the main TPE option will only be allowed to execute files in
>> directories they own that are not group or world-writable, or in 
>> directories
>> owned by root and writable only by root.  If the sysctl option is enabled, 
>> a
>> sysctl option with name "tpe_restrict_all" is created.
>>
>>
>> When running jobs in the vanilla universe that are executed as the
>> submitter, the dir_* directory is chowned by that user and their primary
>> group.  However, when submitting under the standard universe that
>> directory is owned by condor:condor even though execution is still
>> attempted by the submitter which results in a denial by the tpe rule:
>>
>> May  8 11:46:45 bpkroth-tux grsec: From 127.0.0.1: denied untrusted exec
>> of /var/condor/execute/dir_5435/condor_exec.24.0 by
>> /opt/condor-7.0.1-rhel5-dynamic/sbin/condor_starter.std[condor_starter.:5440]
>> uid/euid:1000/1000 gid/egid:100/100, parent
>> /opt/condor-7.0.1-rhel5-dynamic/sbin/condor_starter.std[condor_starter.:5435]
>> uid/euid:0/440 gid/egid:0/440
>>
>> I would have expected the behavior to be similar to the vanilla
>> universe - the dir_* is owned by the user who will be executing the job
>> (either condor, submitter, nobody, etc.).  Is there a reason that's not
>> the case that I'm missing?
>
>
> I believe it's simply historical. Starting a standard universe job follows 
> a different, much older code-path than for the other job types. The 
> directory doesn't need to be owned by the user because the job never 
> accesses files there. It also doesn't need to be owned by user 'condor', 
> but that's how the code was written.

But in this case it does need to be owned by the user (to satisfy the
tpe rule) and an exec is being attempted in that directory (see the log
message for details).  

Are there any thoughts on whether or not condor can be made to set the
proper ownership of dir_* via some conf entry or code tweak, or if there
is another work around like using a wrapper script to move the job
inside of a directory created (and therefore owned) by the executor, or
executing the jobs as some dedicated user?  

I think the former would be tricky and the later still runs into the
same problem unless the dedicated user is condor, but that would kind of
defeat the purpose of the privilege separation since then a job could
interfere with the daemons.

I could of course shut off the tpe feature, but I'd rather not.  The
whole point is to make sure that users aren't executing scripts that
could potentially be tampered with.

Thanks again,
Brian

Attachment: smime.p7s
Description: S/MIME cryptographic signature