subuser-security / subuser

Run programs on linux with selectively restricted permissions.
http://subuser.org
GNU Lesser General Public License v3.0
890 stars 65 forks source link

Sudo users in containers #324

Open mrjk opened 7 years ago

mrjk commented 7 years ago

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 :)

timthelion commented 7 years ago

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.