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

Build a Container Image from Scratch

danishpraka.sh

Post reply on HN
Print view View original

41–50 of 60 posts

Re: Build a Container Image from Scratch

#41

Post by prakashdanish »

m463 wrote: post #4
mortar wrote: post #3

Just learnt about whiteout files from this, thanks! Trying to understand if you purposely included a filename into a layer with the same whiteout prefix “.wh.”, if it would mess with the process that is meant to obfuscate that prefix from subsequent layers.

I learned about $_ echo abc && echo $_ abc abc except it's used with wget... wget URL && tar -xvf $_ does this work? Shouldn't tar take a filename? hmm... also, it says there is an alpine layer with "FROM scratch"??

You're right, that doesn't work the way it is shown. Thankfully, a reader(I'm not sure if it's you) pointed this out with a solution[1] that I plan to add to the post shortly. Again, thanks for pointing this out!

[1] - https://github.com/danishprakash/danishpraka.sh/issues/30

Re: Build a Container Image from Scratch

#42

Post by guappa »

ninkendo wrote: post #38
guappa wrote: post #37

Earlier quoted context omitted.

Docker containers ran as root by default for a great number of years. I'm not even sure if it has now finally been changed. They provided no sandboxing whatsoever.

That’s a horrendously bad take, running as uid0 in the container doesn’t mean “no sandboxing whatsoever”. You’re still namespaced with respect to pids/network interfaces/filesystem/etc, and it’s not supposed to be possible to escape it, even when running as root in the container. Is it possible to do container escapes on occasion? Yes, but each of those is a bug in the Linux kernel that is assigned a CVE and fixed. R…

I see you're not aware of `mknod`?

> Is it possible to do container escapes on occasion? Yes, but each of those is a bug in the Linux kernel that is assigned a CVE and fixed.

No bug, if you have permissions to run mknod it's an entirely by design escape that docker lets you do :)

I wasn't talking about kernel bugs, of course there have been a lot of those causing escapes. I am talking about the default configuration that does absolutely 0 sandboxing. And it's not a bug, it's as intended.

If you want to run as root and don't even touch capabilities… yeah it's root. 0 protection, the stuff in the container is running as root and can easily escape namespaces.

Re: Build a Container Image from Scratch

#43

Post by prakashdanish »

DeathArrow wrote: post #26

By containers here the author seems to understand Docker containers. But there are other types of containers like Linux/OpenVZ containers, Windows containers etc.

Yes that's what I meant, but while not specifically Docker containers, I did mean Linux containers that are most commonly managed by container engines such as Podman or Docker.

Re: Build a Container Image from Scratch

#44

Post by wvh »

godelski wrote: post #7

I often wonder, why isn't systemd-nspawn[0] used more often? It's self-described as "chroot on steroids". IME it pretty much lives up to that name. Makes it really easy to containerize things and since it integrates well with systemd you basically don't have to learn new things. I totally get these are different tools and I don't think nspawn makes docker or podman useless, but I do find it interesting that it isn't…

I used this extensively at the time Docker was up and coming. It worked well, much faster than Docker volumes, but required a lot of scripting and clean-up. What Docker got right, apart from distribution, is better separation of host system and whatever mess you are creating. You do not want to make a mistake bootstrapping an OS or forgetting to `chroot` to the right volume.

Re: Build a Container Image from Scratch

#45

Post by maple3142 »

guappa wrote: post #42
ninkendo wrote: post #38

Earlier quoted context omitted.

That’s a horrendously bad take, running as uid0 in the container doesn’t mean “no sandboxing whatsoever”. You’re still namespaced with respect to pids/network interfaces/filesystem/etc, and it’s not supposed to be possible to escape it, even when running as root in the container. Is it possible to do container escapes on occasion? Yes, but each of those is a bug in the Linux kernel that is assigned a CVE and fixed. R…

I see you're not aware of `mknod`? > Is it possible to do container escapes on occasion? Yes, but each of those is a bug in the Linux kernel that is assigned a CVE and fixed. No bug, if you have permissions to run mknod it's an entirely by design escape that docker lets you do :) I wasn't talking about kernel bugs, of course there have been a lot of those causing escapes. I am talking about the default configuration…

I really wonder how can use escape a container given a root shell created by `docker run --rm -it alpine:3 sh` without using a 0day? Using latest Docker and a reasonably up-to-date Linux kernel of course.

With the command above it is still possible to attack network targets, but let's just ignore it here. I just wonder how is it possible to obtain code execution outside the namespace without using kernel bugs.

Re: Build a Container Image from Scratch

#46

Post by edoceo »

guappa wrote: post #42
ninkendo wrote: post #38

Earlier quoted context omitted.

That’s a horrendously bad take, running as uid0 in the container doesn’t mean “no sandboxing whatsoever”. You’re still namespaced with respect to pids/network interfaces/filesystem/etc, and it’s not supposed to be possible to escape it, even when running as root in the container. Is it possible to do container escapes on occasion? Yes, but each of those is a bug in the Linux kernel that is assigned a CVE and fixed. R…

I see you're not aware of `mknod`? > Is it possible to do container escapes on occasion? Yes, but each of those is a bug in the Linux kernel that is assigned a CVE and fixed. No bug, if you have permissions to run mknod it's an entirely by design escape that docker lets you do :) I wasn't talking about kernel bugs, of course there have been a lot of those causing escapes. I am talking about the default configuration…

Can you show me how? Like, if I'm in a stock debian-slim container, and have mknod, and I've started as root, how can I get from inside the container to the host? Could I create files/run program on the host? Portscan localhost? Do something crazy with the docker socket?

Re: Build a Container Image from Scratch

#47

Post by magicalhippo »

godelski wrote: post #7

I often wonder, why isn't systemd-nspawn[0] used more often? It's self-described as "chroot on steroids". IME it pretty much lives up to that name. Makes it really easy to containerize things and since it integrates well with systemd you basically don't have to learn new things. I totally get these are different tools and I don't think nspawn makes docker or podman useless, but I do find it interesting that it isn't…

> Say, your random self-hosted server thing that isn't escaping your LAN (e.g. Jellyfin or anything like this)

I tried reading your link but I'm none the wiser, so perhaps you could provide the docker-equivalent one-liner to start a Jellyfin instance using systemd-nspawn?

Re: Build a Container Image from Scratch

#48

Post by ninkendo »

guappa wrote: post #42
ninkendo wrote: post #38

Earlier quoted context omitted.

That’s a horrendously bad take, running as uid0 in the container doesn’t mean “no sandboxing whatsoever”. You’re still namespaced with respect to pids/network interfaces/filesystem/etc, and it’s not supposed to be possible to escape it, even when running as root in the container. Is it possible to do container escapes on occasion? Yes, but each of those is a bug in the Linux kernel that is assigned a CVE and fixed. R…

I see you're not aware of `mknod`? > Is it possible to do container escapes on occasion? Yes, but each of those is a bug in the Linux kernel that is assigned a CVE and fixed. No bug, if you have permissions to run mknod it's an entirely by design escape that docker lets you do :) I wasn't talking about kernel bugs, of course there have been a lot of those causing escapes. I am talking about the default configuration…

Yeah you’re going to need to elaborate and post your sources here. If there’s zero protection at all, show how I can run `docker run -it alpine sh` and break out of the container. Without exploiting any 0days.

No, --privileged doesn’t count. No, --cap-add= doesn’t count. The claim here is that docker has “zero sandboxing” by default, so you’re going to need to show that you don’t need either of those. Not just moving the goalposts and saying you can break out if you use the command line flag that literally says “privileged”.

Re: Build a Container Image from Scratch

#49

Post by mdaniel »

guappa wrote: post #42
ninkendo wrote: post #38

Earlier quoted context omitted.

That’s a horrendously bad take, running as uid0 in the container doesn’t mean “no sandboxing whatsoever”. You’re still namespaced with respect to pids/network interfaces/filesystem/etc, and it’s not supposed to be possible to escape it, even when running as root in the container. Is it possible to do container escapes on occasion? Yes, but each of those is a bug in the Linux kernel that is assigned a CVE and fixed. R…

I see you're not aware of `mknod`? > Is it possible to do container escapes on occasion? Yes, but each of those is a bug in the Linux kernel that is assigned a CVE and fixed. No bug, if you have permissions to run mknod it's an entirely by design escape that docker lets you do :) I wasn't talking about kernel bugs, of course there have been a lot of those causing escapes. I am talking about the default configuration…

> I see you're not aware of `mknod`?

Try harder, friend, those require granted capabilities

  $ PAGER=cat man 7 capabilities | grep -C1 MKNOD

       CAP_MKNOD (since Linux 2.4)
              Create special files using mknod(2).

  $ docker run --rm -it public.ecr.aws/docker/library/ubuntu:24.04 /usr/bin/mknod fred b 252 4
  /usr/bin/mknod: fred: Operation not permitted

Re: Build a Container Image from Scratch

#50

Post by mdaniel »

vendiddy wrote: post #27
MyOutfitIsVague wrote: post #17

Earlier quoted context omitted.

I want to make a small note, in that `$_` is a special Bashism (though it is supported widely), but Parameter Expansion is POSIX-standard and will work on all POSIX-compliant shells, not just Bash. https://pubs.opengroup.org/onlinepubs/009604499/utilities/xc...

You know I just realized after all these years I still don't quite know what a shell is. You have iTerm, Terminal, etc. But what do those do? Those are not the shells themselves right?

I wanted to offer that (if you are "C handy") writing your own shell is a super informative exercise. We had to write our own shell in my operating system class at GT and I actually got it working well enough that I could "exec ./myshell" and use it for some day to day stuff. I felt empowered

I tried to dig up the course but naturally things are wwaaaaaaay different now than back in my day. But OCW has something similar https://ocw.mit.edu/courses/6-828-operating-system-engineeri... and does ship the source files https://ocw.mit.edu/courses/6-828-operating-system-engineeri... although I have no idea why that's only present in a graduate level class

Post reply on HN