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

21–30 of 87 posts

Re: Linux containers in a few lines of code

#21

Post by lmuench »

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?

Docker has a concept of layered images where only the top-layer is writable. The layer above the "scratch"[1] image usually contain all the files of the base images OS and that's what you set your root directory to. The writable layer disappears when the container is stopped. If you mount your DIY container into /tmp for example, the process running inside your container won't be able to access any OS functionality. You couldn't run a web server in such a container for instance. On the other hand, whatever your containerized process writes into the mounted part of your hard disk won't disappear when the container stops. Because of that, I wouldn't run untrusted code in it.

[1] https://hub.docker.com/_/scratch

Re: Linux containers in a few lines of code

#22

Post by rantwasp »

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?

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.

Re: Linux containers in a few lines of code

#23

Post by rantwasp »

lmuench wrote: post #21
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?

Docker has a concept of layered images where only the top-layer is writable. The layer above the "scratch"[1] image usually contain all the files of the base images OS and that's what you set your root directory to. The writable layer disappears when the container is stopped. If you mount your DIY container into /tmp for example, the process running inside your container won't be able to access any OS functionality.…

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

Re: Linux containers in a few lines of code

#24

Post by mehrdadn »

lmuench wrote: post #21
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?

Docker has a concept of layered images where only the top-layer is writable. The layer above the "scratch"[1] image usually contain all the files of the base images OS and that's what you set your root directory to. The writable layer disappears when the container is stopped. If you mount your DIY container into /tmp for example, the process running inside your container won't be able to access any OS functionality.…

I see, thanks. It's just a matter of preparing the directory before and cleaning it up afterward though, right? Not a security hole exactly?

Re: Linux containers in a few lines of code

#25

Post by lmuench »

mehrdadn wrote: post #24
lmuench wrote: post #21

Earlier quoted context omitted.

Docker has a concept of layered images where only the top-layer is writable. The layer above the "scratch"[1] image usually contain all the files of the base images OS and that's what you set your root directory to. The writable layer disappears when the container is stopped. If you mount your DIY container into /tmp for example, the process running inside your container won't be able to access any OS functionality.…

I see, thanks. It's just a matter of preparing the directory before and cleaning it up afterward though, right? Not a security hole exactly?

Correct.

Re: Linux containers in a few lines of code

#26

Post by mehrdadn »

rantwasp wrote: post #22
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?

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.

Re: Linux containers in a few lines of code

#27

Post by lmuench »

rantwasp wrote: post #23
lmuench wrote: post #21

Earlier quoted context omitted.

Docker has a concept of layered images where only the top-layer is writable. The layer above the "scratch"[1] image usually contain all the files of the base images OS and that's what you set your root directory to. The writable layer disappears when the container is stopped. If you mount your DIY container into /tmp for example, the process running inside your container won't be able to access any OS functionality.…

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.

Re: Linux containers in a few lines of code

#28

Post by rantwasp »

streb-lo wrote: post #19

Anyone want to chime in on why pivot_root is preferable to a chroot jail? It's kind of hand-waved in the article.

pivot_root is supposed to switch the whole system to a new root. chroot applies to a process, but the underlying system keeps going with what it had.

Re: Linux containers in a few lines of code

#29

Post by mehrdadn »

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.

I'm not sure if this is what the parent is referring to but there are overlayfs and unionfs in Ubuntu for example.

Re: Linux containers in a few lines of code

#30

Post by rantwasp »

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.

start with: https://windsock.io/the-overlay-filesystem/

after that read more about overlay, overlay fs, for historical reasons aufs.

Post reply on HN