subuser icon indicating copy to clipboard operation
subuser copied to clipboard

Sudo users in containers

Open mrjk opened this issue 8 years ago • 1 comments

Hi,

I'm making some experiments with subuser (master branch, not stable) and sudo subusers. In my permission file, I have:

{
 "executable": "/bin/bash",
 "maintainer": "mrjk",
 "description": "A simple Debian 8 Shell",
 "access-working-directory": true,
 "basic-common-permissions" : true,
 "sudo" : true
}

However, when I try to sudo into the image, sudo ask me the "subuser" password, which does not exists. So it basically does not work. I found a workaround by adding the "subuser" into allowed sudoers:

# subuserlib/classes/subuserSubmodules/run/runReadyImage.py, line 57
57      if self.subuser.permissions["sudo"]:                                                                     
  1       dockerfileContents += "RUN (umask 337; echo \""+self.user.endUser.name+" ALL=(ALL) NOPASSWD: ALL\" > /e    tc/sudoers.d/allowsudo )\n"
  2       dockerfileContents += "RUN (umask 337; echo \"subuser ALL=(ALL) NOPASSWD: ALL\" >> /etc/sudoers.d/allow    sudo )\n"
  3     return dockerfileContents

This work well with that. BUT, I don't know if the patch is correct, nor I don't get why "self.user.endUser.name" is queried as there is no sign of my username inside the target container ...

But maybe I missed something here ... I've been quite quick by making this report, but feel free to give some hints about following your community best practices :)

mrjk avatar Jun 13 '17 19:06 mrjk

You are right that there is a bug there with regard to the endUser's name being queried. I've been humming and hawing about what to do about the sudo permission. For now, the existence of the "sudo" and "as-root" permissions really creates a false sense of security due to this: https://github.com/subuser-security/subuser/issues/229

Basically, an image can get root ( IN THE CONTAINER ;) ) regardless of whether the permission is set or not :( :( :(

That bug is basically waiting on our future move to launching containers ourselves rather than via Docker.

On 06/13/2017 09:50 PM, mrjk wrote:

Hi,

I'm making some experiments with subuser (master branch, not stable) and sudo subusers. In my permission file, I have:

|{ "executable": "/bin/bash", "maintainer": "mrjk", "description": "A simple Debian 8 Shell", "access-working-directory": true, "basic-common-permissions" : true, "sudo" : true } |

However, when I try to sudo into the image, sudo ask me the "subuser" password, which does not exists. So it basically does not work. I found a workaround by adding the "subuser" into allowed sudoers:

subuserlib/classes/subuserSubmodules/run/runReadyImage.py, line 57

57 if self.subuser.permissions["sudo"]: 1 dockerfileContents+= "RUN (umask 337; echo ""+self.user.endUser.name+" ALL=(ALL) NOPASSWD: ALL" > /e tc/sudoers.d/allowsudo )\n" 2 dockerfileContents+= "RUN (umask 337; echo "subuser ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers.d/allow sudo )\n" 3 return dockerfileContents

This work well with that. BUT, I don't know if the patch is correct, nor I don't get why "self.user.endUser.name" is queried as there is no sign of my username inside the target container ...

But maybe I missed something here ... I've been quite quick by making this report, but feel free to give some hints about following your community best practices :)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/subuser-security/subuser/issues/324, or mute the thread https://github.com/notifications/unsubscribe-auth/ABU7-Og2IHs-u6vNwY4mhR3QpdbEtFIzks5sDuf3gaJpZM4N4_z2.

timthelion avatar Jun 13 '17 20:06 timthelion