[GE users] reserved ports in SGE 6.0

Andy Schwierskott andy.schwierskott at sun.com
Tue Nov 23 16:18:34 GMT 2004


Sean,

>> if you don't have a secure filesystem (like AFS) of course it means your
>> certificates needs to be on a local filesystem to have the full security
>> needs addressed.
>
> Lets suppose that the cluster has a physically secure LAN (such as I
> have).  Someone putting a rogue machine on the network becomes less of a
> concern (and that's the main disadvantage I see of reserved ports).  At
> that point the only way for someone to break the security is for them to
> gain root privileges on a machine.  However, even with AFS, all someone
> has to do is become root, wait for you to login, then a few environment
> variable changes and they have access to all your files in AFS.  As
> such, I'm not sure that AFS with CSP is any more secure than reserved
> ports, in what I consider to be the common case of having a physically
> secure LAN.

I think I'm not getting the point - in AFS it doesn't help you to be root I
think - with the special AFS login binary user root cannot simply login as a
norm user and get access to the user's home directory. Same would be with
DCE.

> As a somewhat related question, if users kept their tickets on local
> harddrives, what systems would they have to be on?  Just the submit and
> admin hosts?  Or the compute nodes as well?

All hosts where SGE commands are executed. If within a job script a qresub
or qsub is done the keys needs to be available on the exec hosts as well.

>> As many sites regards that reserved port security of the r* commands as
>> insecure the same applies to the SGE binaries being using a reserved port.
>> It's not perfect but it may fullfill certain minimum security requiremements
>> for some sites.
>>
>
> Right, reserved ports aren't prefect, but they are better than nothing.
> Especially considering that with the default (non-CSP) install of SGE
> 6.0u1, its relatively easy for a knowledgeable user to to gain root
> access on a compute node.  (If you're not sure how they would do this,
> email and I will answer privately)  As such, I'd like to see reserved
> ports as the minimum security for SGE instead of the current minimum of
> essentially no security.
>
>> In 5.3 all communication (including daemons and commd-commd communication)
>> used the reserved port. Any of the SGE commands which can run in a
>> multithreaded context could not use this feature in 6.0 - this also may
>> include qsub (not sure - needs to be confirmed by a devleoper)!
>
> I'm not sure about the other systems you support (especially with the
> upcoming NT compute node support), however Linux has something called
> capabilities that should help with this.  They should allow a setuid
> program to keep certain bits of root privileges (ie opening a reserved
> port), but drop the rest.
>
> I'm a little surprised to heard that qsub is threaded.  I can understand
> sge_qmaster being threaded, but not sure I see why qsub needs to be.

qsub is no build on top of Japi - an internal API which is used for DRMAA.
In DRMAA and wit "qsub -sync" you can wait (asynchronously) for the end of a
job - this is implemented as a thread.

Though most command line commands do not use actively threads (and execd and
scheduler as well today) this may change at any time.

Christian who developed the new commlib and who suggested that you file an
RFE certainly can make a better assessment what needs to be done on the
technical side to support the reserved port security mode in 6.0 - the final
decision will then depend on time and priorities whether the Sun developers
will implement this functionality. Of course, being an open source project
there's the option for other to work on this as well.

> Along those lines, do you know why sge_qmaster needs to open any
> outgoing ports?  I thought all the execd's opened ports to sge_qmaster.
> So, sge_qmaster should be able to send jobs/etc over those connections.

It does - to connect to other execds.

Andy

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net




More information about the gridengine-users mailing list