4 ms·

Isn't a lot of this what containerization was supposed to solve? Why are they reimplementing file system isolation from scratch when jails and chroots exist? Wh

Isn't a lot of this what containerization was supposed to solve? Why are they reimplementing file system isolation from scratch when jails and chroots exist? Why do they have to reason about arbitrary HTTP requests when firewalls and content filtering exist?

LtWorf 5mo ago
The answer is that they probably aren't aware of all these things.
lelanthran 5mo ago
Because they don't know what they are doing. In any case, a proxy makes sense, just not for the reasons they give.
- ptx 5mo ago
  And it sounds like the proxy can be easily circumvented by the agent, since it only applies within the Node process and the agent can execute arbitrary external commands. (The filesystem wrapper API sounds even more pointless. The risk it protects against seems insignificant compared to the other risks associated with their system.)
  - solarkraft 5mo ago
    The proxy can be circumvented if the agent can execute arbitrary commands. This is where you’d start if you were planning to enable a world in which it’s more deliberately scoped.
nemomarx 5mo ago
People are running these as a program under their admin permissions, right? That seems to be the root problem to me. Start with having it run under its own user and you could use firewalls and permissions and keep it siloed to some Home directory or etc that you just copy files to?
nyrikki 5mo ago
Namespaces and cgroups allow for resource accounting and limited isolation between trusted processes. It is only through hard work and luck that they have been usable in the k8s/docker world. To be 100% clear, namespaces are not a security feature in themselves, but can be used to run processes with reduced privileges and improved isolation, but not for untrusted code. A few reasons. 1) Kernel features explicitly need to support namespaces, and only the portions that support namespaces have increased isolation, any syscall, socket family, etc… can provide an attack vector for the global kernel. 2) The methods to further constrain processes like LSMs, SecComp, eBPF system calling typically are not implemented by common container images and are difficult for users to develop and deploy. 3) User namespaces have actually increased exposure to user data, if protecting the system itself because of the proliferation of capabilities(7)[0]. Capabilities were designed as a vertical slice of superior(root) user functionality, and the contract is much different than people expect[1][2] We will have to see where things go, but as far as untrusted code, no containers/namespaces/etc… are not sufficient at all. There are just too many holes in the shared kernel and several socket() based backends that are used through netlink etc… Here you can see just how insane the number of default capabilities are granted to every user right now. $ grep ^CapBnd /proc/$$/status CapBnd: 000001ffffffffff $ capsh --decode=000001ffffffffff 0x000001ffffffffff=cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read,cap_perfmon,cap_bpf,cap_checkpoint_restore [0] https://man7.org/linux/man-pages/man7/capabilities.7.html https://man7.org/linux/man-pages/man7/capabilities.7.html [1] https://elixir.bootlin.com/linux/v7.0.1/source/kernel/capability.c#L404 https://elixir.bootlin.com/linux/v7.0.1/source/kernel/capabi... [2] https://www.kernel.org/doc/html/latest/admin-guide/namespaces/compatibility-list.html https://www.kernel.org/doc/html/latest/admin-guide/namespace...
- 3eb7988a1663 5mo ago
  So then how does bubblewrap/firejail do it through namespaces?
vrganj 5mo ago
The people building this aren't good at engineering reliable systems, as evidenced by the incredibly wasteful core premise of what they're doing.
felixgallo 5mo ago
No, containerization has nothing to do with secure separation and never has.

LtWorf 5mo ago

The answer is that they probably aren't aware of all these things.

lelanthran 5mo ago

Because they don't know what they are doing. In any case, a proxy makes sense, just not for the reasons they give.

ptx 5mo ago
And it sounds like the proxy can be easily circumvented by the agent, since it only applies within the Node process and the agent can execute arbitrary external commands. (The filesystem wrapper API sounds even more pointless. The risk it protects against seems insignificant compared to the other risks associated with their system.)
- solarkraft 5mo ago
  The proxy can be circumvented if the agent can execute arbitrary commands. This is where you’d start if you were planning to enable a world in which it’s more deliberately scoped.

nemomarx 5mo ago

People are running these as a program under their admin permissions, right? That seems to be the root problem to me. Start with having it run under its own user and you could use firewalls and permissions and keep it siloed to some Home directory or etc that you just copy files to?

nyrikki 5mo ago

Namespaces and cgroups allow for resource accounting and limited isolation between trusted processes. It is only through hard work and luck that they have been usable in the k8s/docker world. To be 100% clear, namespaces are not a security feature in themselves, but can be used to run processes with reduced privileges and improved isolation, but not for untrusted code. A few reasons. 1) Kernel features explicitly need to support namespaces, and only the portions that support namespaces have increased isolation, any syscall, socket family, etc… can provide an attack vector for the global kernel. 2) The methods to further constrain processes like LSMs, SecComp, eBPF system calling typically are not implemented by common container images and are difficult for users to develop and deploy. 3) User namespaces have actually increased exposure to user data, if protecting the system itself because of the proliferation of capabilities(7)[0]. Capabilities were designed as a vertical slice of superior(root) user functionality, and the contract is much different than people expect[1][2] We will have to see where things go, but as far as untrusted code, no containers/namespaces/etc… are not sufficient at all. There are just too many holes in the shared kernel and several socket() based backends that are used through netlink etc… Here you can see just how insane the number of default capabilities are granted to every user right now. $ grep ^CapBnd /proc/$$/status CapBnd: 000001ffffffffff $ capsh --decode=000001ffffffffff 0x000001ffffffffff=cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read,cap_perfmon,cap_bpf,cap_checkpoint_restore [0] https://man7.org/linux/man-pages/man7/capabilities.7.html https://man7.org/linux/man-pages/man7/capabilities.7.html [1] https://elixir.bootlin.com/linux/v7.0.1/source/kernel/capability.c#L404 https://elixir.bootlin.com/linux/v7.0.1/source/kernel/capabi... [2] https://www.kernel.org/doc/html/latest/admin-guide/namespaces/compatibility-list.html https://www.kernel.org/doc/html/latest/admin-guide/namespace...

3eb7988a1663 5mo ago
So then how does bubblewrap/firejail do it through namespaces?

vrganj 5mo ago

The people building this aren't good at engineering reliable systems, as evidenced by the incredibly wasteful core premise of what they're doing.

felixgallo 5mo ago

No, containerization has nothing to do with secure separation and never has.