4 ms·

Containers and namespaces are not about security. They are about not having singleton objects at the OS level. Would have called it virtualization if the word w

Containers and namespaces are not about security. They are about not having singleton objects at the OS level. Would have called it virtualization if the word wasn't so overloaded already. There is a big difference that somehow everyone misses. A bypassable security mechanism is worse than useless. A bypassable virtualization mechanism is useful. It is useful to be able to have a separate root filesystem just for this program - even if a malicious program is still able to detect it's not the true root. As about SEL4 - it is so elegant because it leaves all the difficult problems to the upper layer (coincidentally making them much more difficult).

alphazard 1y ago
> As about SEL4 - it is so elegant because it leaves all the difficult problems to the upper layer (coincidentally making them much more difficult). I completely buy this as an explanation for why SEL4 for user environments hasn't (and probably will never) take off. But there's just not that much to do to connect a server application to the network, where it can access all of its resources. I think a better explanation for the lack of server side adoption is poor marketing, lack of good documentation, and no company selling support for it as a best practice.
- frumplestlatz 1y ago
  The lack of adoption is because it’s not a complete operating system. Using sel4 on a server requires complex software development to produce an operating environment in which you can actually do anything. I’m not speaking ill of sel4; I’m a huge fan, and things like it’s take-grant capability model are extremely interesting and valuable contributions. It’s just not a usable standalone operating system. It’s a tool kit for purpose-built appliances, or something that you could, with an enormous amount of effort, build a complete operating system on top of.
  - josephg 1y ago
    Yes. I really hope someone builds a nice, usable OS with SeL4 as a base. If SeL4 is like the linux kernel, we need a userland (GNU). And a distribution that's simple to install and make use of. I'd love to work on this. It'd be a fun problem!
    - boredatoms 1y ago
      seL4 needs a ‘the rest of the kernel’ to be like linux
      - josephg 1y ago
        It needs device drivers for modern x86 hardware. And filesystems, and a TCP stack. All of that code can be done in "SeL4 userland", but yeah - I see your point. Are there any projects like that going on? It feels like an obvious thing.
        frumplestlatz 1y ago
        A lot of deployments essentially virtualize Linux or run portions of NetBSD (e.g. via their "rump" kernel mechanism) to achieve driver support, file systems, etc. That's not really a general-purpose solution, though. There is work within major consumer product companies building such things (either with sel4, or things based on sel4's ideas), and there's Genode on seL4.
        LargoLasskhyfv 1y ago
        Are you aware of https://genode.org https://genode.org ?
- tliltocatl 1y ago
  > But there's just not that much to do to connect a server application to the network, where it can access all of its resources. If you only care to run stateless stuff that never write anything (or at least never read what they wrote) - it's comparatively easy. Still gotta deal with the thousand drivers - even on the server there are a lot of quirky stuff. But then you gotta run the database somewhere. And once you run a database you get all the problems Linus warned about. So you gotta run the database on a separate Linux box (at that point - what do you win vs. using Linux for everything?) or develop a new database tailored for SeL4 (and that's quite a bit more complex than an OS kernel). An elegant solution that only solves a narrow set of cases stands no chance over a crude solution that solves every case. Also, with the current sexy containerized stacks it's easy to forget, but having same kind of environment on the programmer's workbench and on the sever was once Unix's main selling point. It's kinda expensive to support a separate abstraction stack for a single purpose.
topspin 1y ago
> Containers and namespaces are not about security True. Yet containers, or more precisely the immutable images endemic to container systems, directly address the hardest part of application security: the supply chain. Between the low effort and risk entailed when revising images to address endlessly emerging vulnerabilities, and enabling systematized auditing of immutable images, container images provide invaluable tools for security processes. I know about Nix and other such approaches. I also know these are more fragile than the deeply self-contained nature of containers and their images. That's why containers and their image paradigm have won, despite all the well-meaning and admirable alternatives. > A bypassable security mechanism is worse than useless Also true. Yet this is orthogonal to the issues of supply chain management. If tomorrow, all the problems of escapable containers were somehow solved, whether by virtual machines on flawless hypervisors, or formally verified microkernels, or any other conceivable isolation mechanism, one would still need some means to manage the "content" of disparate applications, and container systems and the image paradigm would still be applicable.
- otabdeveloper4 1y ago
  > I also know these are more fragile than the deeply self-contained nature of containers and their images Not really. People only use Nix because it doesn't randomly break, bitrot or require arcane system setup. Unlike containers. You really need k8s or something like it to mould Docker containers into something manageable.
  - XorNot 1y ago
    Containers don't break in any of those ways, but rebuilding the images with updates does and the same is entirely true of nix.
    - otabdeveloper4 1y ago
      No, because Nix configuration is declarative and statically checked. Containers is "run these random shell commands I copy pasted from the internet on top of this random OS image I pulled from the internet, #yolo".
coppsilgold 1y ago
> Containers and namespaces are not about security An escape from properly configured container/namespaces is a kernel 0day. Or a 0day in whatever protocol the isolated workload talks to the outside with.
graemep 1y ago
> Containers and namespaces are not about security People keep saying that, but I do not get it. If an attack that would work without a container, fails from inside a container (e.g. because it cannot read or write a particular file, or it cannot) it is better security. > A bypassable security mechanism is worse than useless. It needs the bypass to exist, and it needs an extra step to actually bypass it. Any security mechanism (short of air gaps) might have a bypass. > even if a malicious program is still able to detect it's not the true root. Also true for security unless it can read or write to the true root.
- tliltocatl 1y ago
  You can use containers as a security measure, but I'd argue that if (when) it fails in a spectacular way (see e. g. abstract sockets for an interesting past issue) it's your fault and not a zero-day in the kernel as a sibling comment suggest. To put it a bit less harsh - containers are not just for security and containerization tools have to balance security vs usability.
  - graemep 1y ago
    Yes, I do not think we disagree much. I use containers as an extra security measure. i.e. as a way of reducing the chance that a compromise of one process will lead to a compromise of the rest of the system. That said, I would guess that providers of container hosting must be fairly confident that they can keep them secure. I do not know what extra precautions they take though.
deleted 1y ago
[deleted]
man8alexd 1y ago
> A bypassable security mechanism is worse than useless Looks like the Nirvana fallacy.

alphazard 1y ago

> As about SEL4 - it is so elegant because it leaves all the difficult problems to the upper layer (coincidentally making them much more difficult). I completely buy this as an explanation for why SEL4 for user environments hasn't (and probably will never) take off. But there's just not that much to do to connect a server application to the network, where it can access all of its resources. I think a better explanation for the lack of server side adoption is poor marketing, lack of good documentation, and no company selling support for it as a best practice.

frumplestlatz 1y ago
The lack of adoption is because it’s not a complete operating system. Using sel4 on a server requires complex software development to produce an operating environment in which you can actually do anything. I’m not speaking ill of sel4; I’m a huge fan, and things like it’s take-grant capability model are extremely interesting and valuable contributions. It’s just not a usable standalone operating system. It’s a tool kit for purpose-built appliances, or something that you could, with an enormous amount of effort, build a complete operating system on top of.
- josephg 1y ago
  Yes. I really hope someone builds a nice, usable OS with SeL4 as a base. If SeL4 is like the linux kernel, we need a userland (GNU). And a distribution that's simple to install and make use of. I'd love to work on this. It'd be a fun problem!
  - boredatoms 1y ago
    seL4 needs a ‘the rest of the kernel’ to be like linux
    - josephg 1y ago
      It needs device drivers for modern x86 hardware. And filesystems, and a TCP stack. All of that code can be done in "SeL4 userland", but yeah - I see your point. Are there any projects like that going on? It feels like an obvious thing.
      - frumplestlatz 1y ago
        A lot of deployments essentially virtualize Linux or run portions of NetBSD (e.g. via their "rump" kernel mechanism) to achieve driver support, file systems, etc. That's not really a general-purpose solution, though. There is work within major consumer product companies building such things (either with sel4, or things based on sel4's ideas), and there's Genode on seL4.
      - LargoLasskhyfv 1y ago
        Are you aware of https://genode.org https://genode.org ?
tliltocatl 1y ago
> But there's just not that much to do to connect a server application to the network, where it can access all of its resources. If you only care to run stateless stuff that never write anything (or at least never read what they wrote) - it's comparatively easy. Still gotta deal with the thousand drivers - even on the server there are a lot of quirky stuff. But then you gotta run the database somewhere. And once you run a database you get all the problems Linus warned about. So you gotta run the database on a separate Linux box (at that point - what do you win vs. using Linux for everything?) or develop a new database tailored for SeL4 (and that's quite a bit more complex than an OS kernel). An elegant solution that only solves a narrow set of cases stands no chance over a crude solution that solves every case. Also, with the current sexy containerized stacks it's easy to forget, but having same kind of environment on the programmer's workbench and on the sever was once Unix's main selling point. It's kinda expensive to support a separate abstraction stack for a single purpose.

topspin 1y ago

> Containers and namespaces are not about security True. Yet containers, or more precisely the immutable images endemic to container systems, directly address the hardest part of application security: the supply chain. Between the low effort and risk entailed when revising images to address endlessly emerging vulnerabilities, and enabling systematized auditing of immutable images, container images provide invaluable tools for security processes. I know about Nix and other such approaches. I also know these are more fragile than the deeply self-contained nature of containers and their images. That's why containers and their image paradigm have won, despite all the well-meaning and admirable alternatives. > A bypassable security mechanism is worse than useless Also true. Yet this is orthogonal to the issues of supply chain management. If tomorrow, all the problems of escapable containers were somehow solved, whether by virtual machines on flawless hypervisors, or formally verified microkernels, or any other conceivable isolation mechanism, one would still need some means to manage the "content" of disparate applications, and container systems and the image paradigm would still be applicable.

otabdeveloper4 1y ago
> I also know these are more fragile than the deeply self-contained nature of containers and their images Not really. People only use Nix because it doesn't randomly break, bitrot or require arcane system setup. Unlike containers. You really need k8s or something like it to mould Docker containers into something manageable.
- XorNot 1y ago
  Containers don't break in any of those ways, but rebuilding the images with updates does and the same is entirely true of nix.
  - otabdeveloper4 1y ago
    No, because Nix configuration is declarative and statically checked. Containers is "run these random shell commands I copy pasted from the internet on top of this random OS image I pulled from the internet, #yolo".

coppsilgold 1y ago

> Containers and namespaces are not about security An escape from properly configured container/namespaces is a kernel 0day. Or a 0day in whatever protocol the isolated workload talks to the outside with.

graemep 1y ago

> Containers and namespaces are not about security People keep saying that, but I do not get it. If an attack that would work without a container, fails from inside a container (e.g. because it cannot read or write a particular file, or it cannot) it is better security. > A bypassable security mechanism is worse than useless. It needs the bypass to exist, and it needs an extra step to actually bypass it. Any security mechanism (short of air gaps) might have a bypass. > even if a malicious program is still able to detect it's not the true root. Also true for security unless it can read or write to the true root.

tliltocatl 1y ago
You can use containers as a security measure, but I'd argue that if (when) it fails in a spectacular way (see e. g. abstract sockets for an interesting past issue) it's your fault and not a zero-day in the kernel as a sibling comment suggest. To put it a bit less harsh - containers are not just for security and containerization tools have to balance security vs usability.
- graemep 1y ago
  Yes, I do not think we disagree much. I use containers as an extra security measure. i.e. as a way of reducing the chance that a compromise of one process will lead to a compromise of the rest of the system. That said, I would guess that providers of container hosting must be fairly confident that they can keep them secure. I do not know what extra precautions they take though.

deleted 1y ago

[deleted]

man8alexd 1y ago

> A bypassable security mechanism is worse than useless Looks like the Nirvana fallacy.