131–140 of 144 posts
Earlier quoted context omitted.
Are you on a non linux host? I assume docker is a lot less heavy on resources on linux than on mac&win.
they have to be. Docker is extremely light weight on a linux host.
Why JavaScript instead of something more performant?
Normally the language for doing this kind of system building would be .. Bourne shell. Or Perl/Python.
TBH, I think the code would be a lot simpler if it was just Bash.
Earlier quoted context omitted.
You're confusing JS and NodeJS. NodeJS has more stdlib stuff; opening files, for example.
Virtually everything is a dependency in JavaScript, whether you're using node.js or not. One need look no further than your citation of `open()` as the proof that the nodejs environment "has more stdlib stuff". If the operating environment can run in a context where file IO happens, a native file open function is about the most basic baseline there is. It's absolutely not a good look for "well, we have `open()`!" to…
Can someone dumb this down for me? What _exactly_ is going on here? > slim will build a micro-vm from a Dockerfile. Slim works by building and extracting a rootfs from a Dockerfile, and then merging that filesystem with a small minimal kernel that runs in RAM. > This results in a real VM that can boot instantly, while using very limited resources. If done properly, slim can allow you to design and build immutable uni…
Dockerfile.s must be progressively replaced with Nix recipes then we'd get lockfiles, upgradable dependencies, some day even reproducible builds!
Can someone dumb this down for me? What _exactly_ is going on here? > slim will build a micro-vm from a Dockerfile. Slim works by building and extracting a rootfs from a Dockerfile, and then merging that filesystem with a small minimal kernel that runs in RAM. > This results in a real VM that can boot instantly, while using very limited resources. If done properly, slim can allow you to design and build immutable uni…
Maybe going a bit off tangent here but really let's all agree that Dockerfile.s are just not good enough for building any kind of software through time. There's no lockfile system and caching is just awkward to work with. Dockerfile.s must be progressively replaced with Nix recipes then we'd get lockfiles, upgradable dependencies, some day even reproducible builds!
https://github.com/weaveworks/footloose
(Disclamer: I'm the author of footloose)
Can slim be used to create an iso? So: Dockerfile > slim > iso
> `$ slim build images/alpine3.8-simple`
> This will add a bootable iso in the slim registry.
Earlier quoted context omitted.
One could argue that the key of virtualization is that a piece of software is run in an environment that pretends to be something else than the actual base system. A VM hypervisor runs an operating system in a way that it looks like as it is running alone on a physical machine, with some fake devices. From inside a container, similarly the environment is fake: it can't see processes outside the container, it's view o…
So at its core it's just a set of access permissions + hiding of "forbidden" stuff? How about RAM and stuff, and hardware - does it get a true answer if querying its system? Or is that stuff virtualized too?
> A docker container is not a VM, it is a regular process, isolated with the use of cgroups and namespaces, possibly protected (like any other process) with selinux/apparmor/etc.
Where virtual machines will actually virtualize a whole machine (down to having BIOS for your imaginary motherboard and a CPU for this imaginary machine), linux containerization virtualizes the resources & environment available to a single running process via the use of namespaces (pid, user, etc) and cgroups (available cpu, memory, etc).
So basically, there's a bunch of code in the kernel (shared between all containers) that enables the accurate reporting of all the "virtualized" resources/environment (cpu, memory, other pids running) -- that code can be exploited, which would be a "container escape". Dirty Cow[1] is an example of one of these escapes.
Earlier quoted context omitted.
The kernel
But per the other reply, containers are a lot less "contained" than VM's? I.e. if a program wants to list its set of processes, the host could fuck up and show them some from outside its container - whereas for the same thing to happen by a VM, it would have to have code to read that outside stuff, functionality it might not even contain... so vm's seem safer than containers... is that right?
> Simply put, containers are just processes, and as such they are governed by the kernel like any other process. Thus any kernel-land vulnerability which yields arbitrary code execution can be exploited to escape a container. To demonstrate this, Capsule8 Labs has created an exploit that removes the process from its confines and gives it root access in the Real World. Let’s take a look at what was involved.
(I don't know much about capsule8 as a company is but that article[0] is pretty informative and seems spot on from what I read)
If you can infiltrate a process (let's say a web server) running in a container and know a kernel exploit that can be used to get past these limitations (a "container escape"), then you can use them and get root on the main system.
If that same process was running in a VM (without a container), you need to:
- Infiltrate the process
- Kernel exploit to gain root (assuming the program wasn't running under it) in the VM
- Escape the VM (i.e. use the kernel or whatever else to actually break past the barriers of the hypervisor which was running the vm -- qemu +/- kvm, hyperv,etc) -- aka a "virtual machine escape"[1]
- Gain root on the host system (assuming the process that spawned the hypervisor wasn't running as root)
Generally, virtual machine security is pretty good these days, by virtue of being around longer and having more exposure and eyes looking for exploits.
[0]: https://capsule8.com/blog/practical-container-escape-exercis...
Earlier quoted context omitted.
So at its core it's just a set of access permissions + hiding of "forbidden" stuff? How about RAM and stuff, and hardware - does it get a true answer if querying its system? Or is that stuff virtualized too?
Super late but I have an comment[0] that answers this relatively decently, particularly this sentence: > A docker container is not a VM, it is a regular process, isolated with the use of cgroups and namespaces, possibly protected (like any other process) with selinux/apparmor/etc. Where virtual machines will actually virtualize a whole machine (down to having BIOS for your imaginary motherboard and a CPU for this ima…