Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux containers in a few lines of code

zserge.com

Post reply on HN
Print view View original

31–40 of 87 posts

Re: Linux containers in a few lines of code

#31

Post by rantwasp »

mehrdadn wrote: post #26
rantwasp wrote: post #22

Earlier quoted context omitted.

here is a secret: there is no such thing as a container. it’s an abstraction we made up and containers rely on kernel features. if you use those features correctly it’s as secure as it gets - chances are that if you’re going to roll your own you’ll miss some things.

That doesn't answer my question at all. I'm well aware containers aren't a "real thing". My entire question was about the "if" part that you didn't address. Is anything missed here? is my question.

in theory, it’s a secure as the kernel if your code does the right thing.

that being said, the attack surface is wider than say if you would run it in a VM or its own physical machine

Re: Linux containers in a few lines of code

#32

Post by mehrdadn »

rantwasp wrote: post #31
mehrdadn wrote: post #26

Earlier quoted context omitted.

That doesn't answer my question at all. I'm well aware containers aren't a "real thing". My entire question was about the "if" part that you didn't address. Is anything missed here? is my question.

in theory, it’s a secure as the kernel if your code does the right thing. that being said, the attack surface is wider than say if you would run it in a VM or its own physical machine

Well obviously "if your code does the right thing" then it's going to be secure rather than insecure... by definition. That's again a pretty unhelpful tautology.

I'm asking about the code in the webpage, not code I'm writing personally. I'm saying let's assume it has error-handling added to it. That's it. I am not writing any code otherwise. Is that code doing "the right thing"? Or are there more things it needs to be doing?

Re: Linux containers in a few lines of code

#33

Post by freedomben »

Spivak wrote: post #17
dmayle wrote: post #4

A little bit of education about container systems in linux[1]. A container system is typically made up a number of components: isolation layer : the piece that limits privileges and resource usage. (On linux, this is usually handled by cgroups and the kernel, but could also be handled by something like kvm for vm-based containers) raw container configuration : Given an image and some metadata (like cpu limits), launc…

I feel like podman is proving that you don't really need the api daemon and a porcelain over runc with a one-off process supervisor is sufficient for a good number of workloads. Being able to run containers like any other process and leave the lifecycle management to systemd is actually really nice.

Could not agree more. As a Fedora user I was mildly intrigued when Podman showed up, I played with it briefly but stopped because most of my projects used docker-compose, which doesn't work with Podman.

When I went to work at Red Hat I decided to really try Podman, and I love it now. Once I discovered that Podman supports Kubernetes Pods (same YAML and all) I realized how clunky docker-compose actually is. Since most of my projects now run in K8s anyway, it's awesome to have the app run as a Pod locally so it can easily be tested with any sidecars in the same configuration.

There are still uses for docker-compose, and I don't expect it to disappear from my life completely any time soon, but Podman does have a great place in my toolkit.

Re: Linux containers in a few lines of code

#34

Post by throwaway8941 »

freedomben wrote: post #33
Spivak wrote: post #17

Earlier quoted context omitted.

I feel like podman is proving that you don't really need the api daemon and a porcelain over runc with a one-off process supervisor is sufficient for a good number of workloads. Being able to run containers like any other process and leave the lifecycle management to systemd is actually really nice.

Could not agree more. As a Fedora user I was mildly intrigued when Podman showed up, I played with it briefly but stopped because most of my projects used docker-compose, which doesn't work with Podman. When I went to work at Red Hat I decided to really try Podman, and I love it now. Once I discovered that Podman supports Kubernetes Pods (same YAML and all) I realized how clunky docker-compose actually is. Since most…

podman-compose works fine for me, despite being advertised as "still under development".

https://github.com/containers/podman-compose

Re: Linux containers in a few lines of code

#35

Post by throwaway8941 »

lmuench wrote: post #27
rantwasp wrote: post #23

Earlier quoted context omitted.

this is the file system not docker itself. you can get the overlay behavior without any docker

Can you point me to some online resources? I'd like to learn more about this.

https://lwn.net/Articles/324291/

https://lwn.net/Articles/325369/

https://lwn.net/Articles/327738/

Re: Linux containers in a few lines of code

#36

Post by zajio1am »

mehrdadn wrote: post #20

Could someone comment on how secure such a container is, at least nominally? Should I be able to theoretically run untrusted code on such a container if the system is bug-free and I add proper error-checking to the code? Or are there things that you'd need to worry about the code being able to access? Any considerations regarding sudo permissions?

The code from the article misses an important thing w.r.t. security - user namespaces, which can be used to map container UIDs to a subset of host UIDs and container root to non-root user. But it is a namespace that is more complicated to configure than others.

Re: Linux containers in a few lines of code

#37

Post by mmastrac »

Big caution here. Do NOT use this style of code to invoke ip tools. This was the cause of a huge number of security vulnerabilities on Android in the first few years. Even if you're hardcoding interfaces to start, it's likely someone else will drive by later on and replace one of the args with %s.

> system("ip link add veth0 type veth peer name veth1");

Always, always, always use exec*() APIs.

Re: Linux containers in a few lines of code

#38

Post by jeffbee »

mehrdadn wrote: post #20

Could someone comment on how secure such a container is, at least nominally? Should I be able to theoretically run untrusted code on such a container if the system is bug-free and I add proper error-checking to the code? Or are there things that you'd need to worry about the code being able to access? Any considerations regarding sudo permissions?

Big “if”. There has never, in thirty years, been a Linux that lacked a user-to-root privilege escalation path. Running untrusted code in containers is the same as it’s ever been: totally unsafe. VMs are safer, or, minimally, ptrace sandboxes intercepting all syscalls.

Re: Linux containers in a few lines of code

#40

Post by mehrdadn »

zajio1am wrote: post #36
mehrdadn wrote: post #20

Could someone comment on how secure such a container is, at least nominally? Should I be able to theoretically run untrusted code on such a container if the system is bug-free and I add proper error-checking to the code? Or are there things that you'd need to worry about the code being able to access? Any considerations regarding sudo permissions?

The code from the article misses an important thing w.r.t. security - user namespaces, which can be used to map container UIDs to a subset of host UIDs and container root to non-root user. But it is a namespace that is more complicated to configure than others.

Ah thank you! That's what I was looking for.
Post reply on HN