4 ms·

Very interesting work. I have seen OpenBSD's pledge, and unveil systemcalls that achieve this easily for applications running on OpenBSD. Elegant in the way it

Very interesting work. I have seen OpenBSD's pledge, and unveil systemcalls that achieve this easily for applications running on OpenBSD. Elegant in the way it's done. On the other hand, running container images for wmeverything including text editor seems like a NIMBYism in OS and packages. There is a reason why our OSes evolved with package managers. Sharing and reusing common libraries so that they can be updated once safely. Bug in libsodium? Update libsodium in your system, and all applications that use it automatically get new version. With containers, you have to rely on each and every container to update libsodium... Secondly, it takes away the sharing so you have several copies of libraries for each applications you use as containers.. What does it do to memory usage, and disk usage? Very interesting either way, and got me thinking about using such for specific cases.

m_mueller 8y ago
I guess it's give and take - on one hand containers would isolate processes such that a security bug in an application shouldn't allow an attacker to propagate to the rest of the system. On the other, updates are not centralized anymore as you pointed out. Then again, the most commonly used distros have a slow update cycle anyways, so I don't think it would change that much if they rebuild container images rather than packages for each release. Plus, isolation would allow software to be tested independently from each other, so rolling distros could become easier to handle for the maintainers and more stable. IMO from a development perspective it makes sense as a step forward.
the8472 8y ago
It's worse on several levels. The first thing containers do is take away the tools needed (unshare, seccomp syscalls) for an application to secure itself or its children. The pledge/unveil model is far more elegant. > What does it do to memory usage, and disk usage? You'd need a deduplicating filesystem, i.e. btrfs for the storage aspect. For memory consumption you either have to rely on KSM or hope that they will implement page cache sharing it for btrfs. Overlayfs has it but it's less space-efficient. But I agree that this shouldn't be needed because containers shouldn't each ship with their own OS disk image. That's not orthogonal to the security aspect.
- beojan 8y ago
  > You'd need a deduplicating filesystem Until all your packages decide to use different versions of their dependencies.
- muraiki 8y ago
  I found this thread which has some stats on the memory savings achieved through KSM, but the results weren't very impressive.
- compsciphd 8y ago
  you don't need deduplicating file system or ksm. regular file systems and regular shared read only code pages work fine. see the links I posted above, if every package (or a subset of packages based on the underlying source package) in a traditional linux distribution is treated as an independent layer that can be composed together on demand (i.e. what happens when you install a package, except much slower) using a traditional union file system you get deduplication (as every image using that package will be sharing the same exact portion of the file systme) and you get memory sharing for free (for exact same reason, as its fundamentally no different than multiple processes on a single host dynamically linking the same binaries).
  - deleted 8y ago
    [deleted]
  - the8472 8y ago
    In practice containers are siblings with a lot of redundant data, not a layer cake.
compsciphd 8y ago
see https://www.usenix.org/legacy/events/atc10/tech/full_papers/Potter.pdf https://www.usenix.org/legacy/events/atc10/tech/full_papers/..., https://www.usenix.org/legacy/event/lisa11/tech/full_papers/Potter.pdf https://www.usenix.org/legacy/event/lisa11/tech/full_papers/..., and https://patents.google.com/patent/US8589947 https://patents.google.com/patent/US8589947 I'd argue that docker copied this in a degenerate way, but that those papers implemented what you asked for.

m_mueller 8y ago

I guess it's give and take - on one hand containers would isolate processes such that a security bug in an application shouldn't allow an attacker to propagate to the rest of the system. On the other, updates are not centralized anymore as you pointed out. Then again, the most commonly used distros have a slow update cycle anyways, so I don't think it would change that much if they rebuild container images rather than packages for each release. Plus, isolation would allow software to be tested independently from each other, so rolling distros could become easier to handle for the maintainers and more stable. IMO from a development perspective it makes sense as a step forward.

the8472 8y ago

It's worse on several levels. The first thing containers do is take away the tools needed (unshare, seccomp syscalls) for an application to secure itself or its children. The pledge/unveil model is far more elegant. > What does it do to memory usage, and disk usage? You'd need a deduplicating filesystem, i.e. btrfs for the storage aspect. For memory consumption you either have to rely on KSM or hope that they will implement page cache sharing it for btrfs. Overlayfs has it but it's less space-efficient. But I agree that this shouldn't be needed because containers shouldn't each ship with their own OS disk image. That's not orthogonal to the security aspect.

beojan 8y ago
> You'd need a deduplicating filesystem Until all your packages decide to use different versions of their dependencies.
muraiki 8y ago
I found this thread which has some stats on the memory savings achieved through KSM, but the results weren't very impressive.
compsciphd 8y ago
you don't need deduplicating file system or ksm. regular file systems and regular shared read only code pages work fine. see the links I posted above, if every package (or a subset of packages based on the underlying source package) in a traditional linux distribution is treated as an independent layer that can be composed together on demand (i.e. what happens when you install a package, except much slower) using a traditional union file system you get deduplication (as every image using that package will be sharing the same exact portion of the file systme) and you get memory sharing for free (for exact same reason, as its fundamentally no different than multiple processes on a single host dynamically linking the same binaries).
- deleted 8y ago
  [deleted]
- the8472 8y ago
  In practice containers are siblings with a lot of redundant data, not a layer cake.

compsciphd 8y ago

see https://www.usenix.org/legacy/events/atc10/tech/full_papers/Potter.pdf https://www.usenix.org/legacy/events/atc10/tech/full_papers/..., https://www.usenix.org/legacy/event/lisa11/tech/full_papers/Potter.pdf https://www.usenix.org/legacy/event/lisa11/tech/full_papers/..., and https://patents.google.com/patent/US8589947 https://patents.google.com/patent/US8589947 I'd argue that docker copied this in a degenerate way, but that those papers implemented what you asked for.