5 ms·

The problem is every executable can impersonate the user, it has access to do anything the user can do, including deleting or encrypting all their files, readin

The problem is every executable can impersonate the user, it has access to do anything the user can do, including deleting or encrypting all their files, reading ssh private keys etc. Network access is rarely concerning unless the program has access to credentials.

nyrikki 4y ago
Nothing is stopping you from using namespaces, and containers are just namespaces with cgroups etc But containers aren't jails, pid and uid remapping is just remapping. A huge problem container has to drop capabilities on the honor system. In the default docker mode, running as root, anyone who can launch a container can read from any block device if they don't drop the mknod capability as an example. Actually a privileged container can update the bios or even load arbitrary kernel modules in the host context or change kernel parameters as it is a shared kernel. I tried to get the docker folks to add a conf option disallow privileged container but they refused. You can run in user mode now but most people want persistence and other features that don't allow for that. The important point is if you assume containers are a security feature you are going to have a bad time. Jails were bad enough and containers are just one step up from chroots as far as security go. namespace isolation is the main benefit of containers. Selinux and apparmor are far more appropriate than containers for the security concerns. While I don't personally like selinux, apparmor profiles are pretty easy to write.
- nyrikki 4y ago
  Plus the 'leaks' in the Linux process API is even worse as each container may run its own tiny-init Containers make the first point of the OP far worse by adding way more pid namespaces.
Karellen 4y ago
> The problem is every executable can impersonate the user, Um, what? What do you mean by "impersonate" here? What does a process that does not impersonate the user look like? Do you just mean "executables that run as the user"? When you log in, and a shell is started that runs as you, is that shell impersonating the user? When you execute commands, as yourself, those commands run with your credentials. Because you ran them. Isn't that, like, the point?
- dllthomas 4y ago
  Typically, any program I run has the totality of my (regular user) authority, which may let it do things I did not intend. Related: https://en.wikipedia.org/wiki/Ambient_authority https://en.wikipedia.org/wiki/Ambient_authority https://en.wikipedia.org/wiki/Confused_deputy_problem https://en.wikipedia.org/wiki/Confused_deputy_problem https://en.wikipedia.org/wiki/Object-capability_model https://en.wikipedia.org/wiki/Object-capability_model
- derefr 4y ago
  > What does a process that does not impersonate the user look like? A command running inside a virtual machine, maybe?
  - eru 4y ago
    Or check out how iOS and Android use permissions.
traverseda 4y ago
Firejail
bombolo 4y ago
Use firejail then
klooney 4y ago
Bubblewrap is a good tool in this space https://github.com/containers/bubblewrap https://github.com/containers/bubblewrap

nyrikki 4y ago

Nothing is stopping you from using namespaces, and containers are just namespaces with cgroups etc But containers aren't jails, pid and uid remapping is just remapping. A huge problem container has to drop capabilities on the honor system. In the default docker mode, running as root, anyone who can launch a container can read from any block device if they don't drop the mknod capability as an example. Actually a privileged container can update the bios or even load arbitrary kernel modules in the host context or change kernel parameters as it is a shared kernel. I tried to get the docker folks to add a conf option disallow privileged container but they refused. You can run in user mode now but most people want persistence and other features that don't allow for that. The important point is if you assume containers are a security feature you are going to have a bad time. Jails were bad enough and containers are just one step up from chroots as far as security go. namespace isolation is the main benefit of containers. Selinux and apparmor are far more appropriate than containers for the security concerns. While I don't personally like selinux, apparmor profiles are pretty easy to write.

nyrikki 4y ago
Plus the 'leaks' in the Linux process API is even worse as each container may run its own tiny-init Containers make the first point of the OP far worse by adding way more pid namespaces.

Karellen 4y ago

> The problem is every executable can impersonate the user, Um, what? What do you mean by "impersonate" here? What does a process that does not impersonate the user look like? Do you just mean "executables that run as the user"? When you log in, and a shell is started that runs as you, is that shell impersonating the user? When you execute commands, as yourself, those commands run with your credentials. Because you ran them. Isn't that, like, the point?

dllthomas 4y ago
Typically, any program I run has the totality of my (regular user) authority, which may let it do things I did not intend. Related: https://en.wikipedia.org/wiki/Ambient_authority https://en.wikipedia.org/wiki/Ambient_authority https://en.wikipedia.org/wiki/Confused_deputy_problem https://en.wikipedia.org/wiki/Confused_deputy_problem https://en.wikipedia.org/wiki/Object-capability_model https://en.wikipedia.org/wiki/Object-capability_model
derefr 4y ago
> What does a process that does not impersonate the user look like? A command running inside a virtual machine, maybe?
- eru 4y ago
  Or check out how iOS and Android use permissions.

traverseda 4y ago

Firejail

bombolo 4y ago

Use firejail then

klooney 4y ago

Bubblewrap is a good tool in this space https://github.com/containers/bubblewrap https://github.com/containers/bubblewrap