Earlier quoted context omitted.
FreeBSD jails, I would think.
See also: Solaris zones.
Yeah when that giant Oracle boat finally turns we are all in for it.
Abusing Privileged and Unprivileged Linux Containers
41–50 of 54 posts
Re: Abusing Privileged and Unprivileged Linux Containers
#42Earlier quoted context omitted.
This is going to sound amusing at best, but would you clarify what it means to boot? To justify the question a bit: booting traditionally meant physically turning a system on. The boot time included BIOS initialization, a concept now blurred by the advent of virtualization. 150ms is such an absurdly short amount of time that I'm left wondering what booting is in this context.
VMs usually do have BIOS (sometimes you can see it flicker on the screen) but like NeutronBoy said, the hypervisor just creates the virtual hardware devices in a pre-initialized state so the BIOS has to do almost no work and it completes in a fraction of a second. Clear Containers boots even faster by not using BIOS; the hypervisor directly loads the kernel and initrd into RAM. So in this case "booting" means startin…
Actually Clear Containers does have a BIOS, because Linux requires one eg to read E820 data and to set up the virtual video. However the one Clear Containers uses (from kvmtool) is extremely minimal -- it's literally enough of a BIOS just to answer the int calls that modern Linux makes at boot and that's all. IIRC it's hundreds of lines of code only.
Re: Abusing Privileged and Unprivileged Linux Containers
#43Earlier quoted context omitted.
> 150ms is such an absurdly short amount of time that I'm left wondering what booting is in this context. Clear Linux was announced about a year ago, and it does boot absurdly quickly https://clearlinux.org https://lwn.net/Articles/644675/
It does this thanks to a technology called DAX and the fact that systemd boots really fast. https://www.kernel.org/doc/Documentation/filesystems/dax.txt
DAX is a small part of it, but Intel made many changes throughout the stack, mostly to the Linux kernel.
Re: Abusing Privileged and Unprivileged Linux Containers
#44I think what Intel are doing with Clear Containers is really interesting. They are encapsulating containers inside VMs, avoiding the security problems of containers. To do this efficiently they've had to make a bunch of changes on the VM side so the overhead is much smaller than an ordinary VM (of the order of 150ms and 20MB of RAM). I've also been looking at this and am hoping to give a talk about it at the KVM Foru…
Because running a process in a VM doesnt meet what requirement ?
[deleted]
Re: Abusing Privileged and Unprivileged Linux Containers
#45I think what Intel are doing with Clear Containers is really interesting. They are encapsulating containers inside VMs, avoiding the security problems of containers. To do this efficiently they've had to make a bunch of changes on the VM side so the overhead is much smaller than an ordinary VM (of the order of 150ms and 20MB of RAM). I've also been looking at this and am hoping to give a talk about it at the KVM Foru…
Because running a process in a VM doesnt meet what requirement ?
Your question is confusing, what does it mean?
If you meant "running a process in a VM meets what requirement?", the requirement is security, which as the paper here proves is not available with simple containers running as processes on the host.
Re: Abusing Privileged and Unprivileged Linux Containers
#46Earlier quoted context omitted.
150ms to boot the VM that is running the container processes with the stripped down Linux Kernel, lkvm, and DAX. This is about what we observe in the rkt Clear Containers "stage1": https://coreos.com/blog/rkt-0.8-with-new-vm-support/ One note: you can run multiple "container processes", like redis and a redis dashboard, inside of these Clear Container VMs. This means in the case of Kubernetes we will only incur the c…
This is going to sound amusing at best, but would you clarify what it means to boot? To justify the question a bit: booting traditionally meant physically turning a system on. The boot time included BIOS initialization, a concept now blurred by the advent of virtualization. 150ms is such an absurdly short amount of time that I'm left wondering what booting is in this context.
For perspective, I just timed (not very well) how long it takes windows to run the c-program "exit": "int main() { return 0; }", compiled with gcc 4.8.1, -O3 -std=c11 -Wall, stripped[1]. From a warm disc cache it takes ~3ms. From cold(er) it takes ~19s.
Taking a 50x hit to run "exit" from a container doesn't sound bad, but it doesn't sound all that far fetched either.
[1] time util from pstools, as installed by scoop.sh - similar to why gcc (not eg msvc - it's all in my path atm, no work needed :)
Re: Abusing Privileged and Unprivileged Linux Containers
#47Earlier quoted context omitted.
That's interesting...it was my impression that some of the kernel features were added specifically as a result of the kernel patches that were originally part of the OpenVZ project. Once the kernel adopted official primatives the original OpenVZ patches were deprecated. It was also at this time that LXC started with some of the same developers from the OpenVZ project. I could be wrong...but that path dependency seems…
To the best of my knowledge, the container features in the vanilla kernel today (cgroups, as used by LXC, docker, etc) originated at Google, where they were used more for resource allocation than for containerization per se . The kernel patches developed by Virtuozzo/Parallels for OpenVZ were never upstreamed, and were considerably different in design from cgroups.
They're talking about namespaces. Cgroups are not an isolation mechanism, and there have been significant rewrites of the core since Google worked on them. Most of the namespace work came from Odin (Parallels) as well as Virtuozzo and others.
Re: Abusing Privileged and Unprivileged Linux Containers
#48Re: Abusing Privileged and Unprivileged Linux Containers
#49Linux does not have containers. It has namespaces and cgroups. Jails (FreeBSD) and zones (Illumos) are containers. Please, stop claiming containers exist on Linux.
It's like Linux capabilities. The kernel community has a very odd view of history and generally refuses to learn from others' efforts.
Re: Abusing Privileged and Unprivileged Linux Containers
#50>As such, it discloses the names and PIDs of all processes running on the system... So I don't really see how this is considered a big vulnerability, unless the goal is security by obscurity, but then we could go even further and obfuscate the whole system. >NET_RAW abuse Hard to blame LXC/Docker for something that has to do with the configuration of the bridge, plus for some setups this is desired functionality. >Do…
Security by obscurity is relying purely on nondisclosure of information. Minimizing information leakage is sound practice. PIDs, names, etc, can give a lot of information as to the configuration of the app running in your container -- how often external processes are run, potentially vulnerable software that you may be using in utilities, such as an old version of imagemagick, etc. While there's no substitute for kee…
Raw sockets are there for ping. Hopefully we can remove this as distros switch to ICMP sockets finally.