4 ms·

Given the possibility of a container escape, it's far better for the escapee to find himself on the outside as a normal user. Just like with kernel exploits, mo

Given the possibility of a container escape, it's far better for the escapee to find himself on the outside as a normal user. Just like with kernel exploits, most escapes rely on access to esoteric, complicated, or poorly understood devices or functions. Obviously, there are fewer of those in userspace. Imagine, for example, an escape that required arbitrary network control. That would be much harder to pull off (if not impossible) from userspace. There have been and will continue to be parts of the kernel hard-coded to respect UID 0. Until these are all found and fixed (likely many years from now) using usernamespaces to remap root will not provide all the safety one might assume. It is super handy for other users though. Full disclosure - I am both a hatter and a sec guy.

yAnonymous 11y ago
The attacker can install a keylogger as normal user and then wait for the sudo password. How much better is that, really?
- tokenizerrr 11y ago
  How would a normal user go about installing this system-wde keylogger?
  - NoGravitas 11y ago
    It wouldn't be system-wide. You'd need to compromise an interactive user account, install and run the keylogger as them, and wait for them to su or sudo. So it's a means of escalating privileges from a regular user account.
    - tokenizerrr 11y ago
      Right, and your daemons use sub-1000 UIDs and user UIDs start at 1000. In Debian, at least. Other distros have other starting points, but the concept remains the same.
- gtrevorjay 11y ago
  Value for each delta will vary, but every extra step (the need to install a keylogger) or dependency requirement (that this be an interactive node and someone eventually logs in) will decrease your overall chance of penetration. Almost no one has the resources to stand up to a targeted attack from even a mildly capable hacker. Therefore, the risk profile most administrators are working against are attacks of opportunity. In that race, as in the old joke about outrunning your friend instead of a lion, you need only be be some small amount more difficult to crack than the next potential victim.
- icebraining 11y ago
  The user under which the application is running shouldn't even be in the sudo group.
DannoHung 11y ago
Can you speak to the security implications of building the container as a remapped root and running as a user? My understanding is that the most important reason to have root in the container is to install software through the standard measures, but obviously, we don't want to have to run our build process for containers as root on the real host. Given the comparatively restricted behavior, is this a good practice or are there implications of using a remapped root during container build time that would linger on to run time?
- gtrevorjay 11y ago
  That should be fine. The only "lingering" effects would be possibly suid or SELinux labeling oddities, but those are easy to watch out for. And I should have been clear that a remapped root that drops drops privileges and/or transitions into another user is still better than an unremapped root doing the same. It's just that the remapping is not a panacea.

yAnonymous 11y ago

The attacker can install a keylogger as normal user and then wait for the sudo password. How much better is that, really?

tokenizerrr 11y ago
How would a normal user go about installing this system-wde keylogger?
- NoGravitas 11y ago
  It wouldn't be system-wide. You'd need to compromise an interactive user account, install and run the keylogger as them, and wait for them to su or sudo. So it's a means of escalating privileges from a regular user account.
  - tokenizerrr 11y ago
    Right, and your daemons use sub-1000 UIDs and user UIDs start at 1000. In Debian, at least. Other distros have other starting points, but the concept remains the same.
gtrevorjay 11y ago
Value for each delta will vary, but every extra step (the need to install a keylogger) or dependency requirement (that this be an interactive node and someone eventually logs in) will decrease your overall chance of penetration. Almost no one has the resources to stand up to a targeted attack from even a mildly capable hacker. Therefore, the risk profile most administrators are working against are attacks of opportunity. In that race, as in the old joke about outrunning your friend instead of a lion, you need only be be some small amount more difficult to crack than the next potential victim.
icebraining 11y ago
The user under which the application is running shouldn't even be in the sudo group.

DannoHung 11y ago

Can you speak to the security implications of building the container as a remapped root and running as a user? My understanding is that the most important reason to have root in the container is to install software through the standard measures, but obviously, we don't want to have to run our build process for containers as root on the real host. Given the comparatively restricted behavior, is this a good practice or are there implications of using a remapped root during container build time that would linger on to run time?

gtrevorjay 11y ago
That should be fine. The only "lingering" effects would be possibly suid or SELinux labeling oddities, but those are easy to watch out for. And I should have been clear that a remapped root that drops drops privileges and/or transitions into another user is still better than an unremapped root doing the same. It's just that the remapping is not a panacea.