[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [HTCondor-users] Singularity and Charliecloud support for HTCondor?

Am 30.10.2017 um 16:13 schrieb Greg Thain:
> On 10/29/2017 02:29 PM, Oliver Freyermuth wrote:
>> However, it has several basic flaws related to interactive jobs / condor_ssh_to_job:
>> - condor_ssh_to_job ends up in it's own namespaces instead of those of the job
> This is something we are actively thinking about, and would like to fix, both for singularity and docker universe. The basic problem is that we'd really like to run the sshd as non-root, and outside of the container. However, nsenter requires root to enter a container.

Dear Greg, 

this is untrue for containers running with user namespaces, such as (at least):
- Singularity running with setuid root to false.
- Charliecloud. 
For these, you can just do something like:
$ nsenter -U -m --preserve-credentials -t 21546 bash
as the same user running the container(!). [1]
Then, the new "bash" is executed within the very same user namespace as PID 21546, as the same user who opened that namespace, and with the options I used,
also the mount namespace is taken over. 

Since user namespaces are namespaces running without root at any point (and all other solutions require either a setuid root binary, or a root-owned helper daemon),
they would be the main target for implementing "sshd as non-root". 
It's also only for them that running sshd inside the container actually fails: Since all /dev/tty, /dev/pts etc. devices are owned by the overflow UID (see kernel docs). 
In terms of security, they are also the most safe solution: The only potential point of security leak is the kernel itself, not some userspace code in addition. 
So I'd think these are in any case preferred, however, they require a recent enough kernel (something like 3.9 or better 3.10). 

For containers running without user namespace, there is in any case "root" involved in some way. For these, I'm unsure what an elegant solution would be,
apart from introducing something which runs privileged (again) - I believe that technically, any other way is impossible by design. 


[1]: Note that this will currently still fail with Singularity, since they do not implement user namespaces in the way it was foreseen by the kernel. 

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature