Some people see the word “containerization” and confuse it with “sandboxing”. It’s about defining your requirements on a filesystem level. Not security.
Docker gives you plenty of tools to sandbox & isolate your applications. Just like any other consumer-facing product you will have to roll your own security policy.
You can use qemu for pure userspace emulation, without passing /dev/kvm. It'll be slow. Probably unusable for Windows. However I used this kind of emulation to build images with qemu from arm host and it worked OK, like few minutes to boot from Linux image, install some packages, run some commands and shutdown.
Docker is actually great for that kind of applications, because you can run it everywhere: Mac, Windows with one single-line. The only problem is that it's not very convenient to use docker images just as file containers, but it works.
My main advice on Windows Containers is to avoid them at all costs.
A lot of the things that ran in Windows Nano Server worked even better in Linux containers, and a full Windows Server Core container is usually only necessary for .NET Framework, where you will need all of the luck in the world help you with that problem.
Packer and Ansible are also much harder to use for Windows Containers, so if you're already using those to configure VM images and Ansible to perform config mgmt on VMs, get ready for some headaches to make that work against Windows Containers.
Former Windows Container wrangler. First off, why are you using Ansible/Packer against Windows Container images? You wouldn't fault Linux Containers for being terrible to use with Packer/Ansible because you shouldn't be doing that.
Second, Yea, it's only use is Windows specific languages like .Net Framework and various Win32 API applications. Windows Containers works well enough if you are good enough with Powershell to handle various levels of bullshit that comes Windows.
> First off, why are you using Ansible/Packer against Windows Container images ? You wouldn't fault Linux Containers for being terrible to use with Packer/Ansible because you shouldn't be doing that.
You can build Linux containers just fine with Packer/Ansible. But to your point I already stated why I use Ansible and Packer for container images: "if you're already using those to configure VM images and Ansible to perform config mgmt on VMs"
I currently build a number of images with Packer and Ansible across Linux and Windows. I choose not to rewrite all of that from scratch in a crummy Dockerfile when I can just have Packer and Ansible make the images alongside everything else they're already making.
I don’t see any benefits. Security scanners have a harder time to track issues, because they can’t just detect the image is depending on an insecure base image.
It also strips the possibility to deduplicate some base layers, or a partial pull if you already have one of the base layers in the cache (Debian or Ubuntu are very common, you might have even the exact same version already in the layer cache).
Not an expert but I believe the first approach doesn't inherit the metadata, configuration, or layering history from the original image, it just copies the files and folders.
It's different in that it's creating a new unique intermediate layer, but admittedly I'm struggling to see the value for most workflows. I assume there's an important detail I'm missing, as is the usual case with interesting Dockerfiles.
I think it's meant to remove a layer, as you're modifying the base layer rather than altering it through a second layer. Probably to limit size. (but that's a theory)
The first example collapses all the layers into one, which can result in a smaller image than the second
If a layer creates a file and then a subsequent layer deletes it, the deleted file is still present in the image taking up space. If you squash the layers, the deleted file is gone
“scratch” used to be an empty layer, but in newer versions is now just syntax to state that you want a layer without a parent layer
Not when I can read the root filesytem if mknod privilege isn't dropped, update firmware on the EFI partition, load kernel modules in the host namespace etc....
But it is really about the order namespaces start with almost no isolation and you add whatever you want.
Sandboxes and Jails tend to start more restricted by default.
As an example here is an older step by step example of the above. Note how disabling privileged containers at the docker server layer is still not possible as they decided user namespaces were their solution.
ETA: I jumped to conclusions a bit - I thought the Bob Pony ISO distributions were shadier than they were and misread part of the installation details. See the discussion below about the challenges with hosting these older Windows ISOs.
From the README:
> Is this project legal?
> Yes, this project contains only open-source code and does not distribute any copyrighted material. Neither does it try to circumvent any copyright protection measures. So under all applicable laws, this project would be considered legal.
From install.sh:
if [[ "${VERSION,,}" == "win7x64" ]]; then
DETECTED="win7x64"
VERSION="https://dl.bobpony.com/windows/7/
en_windows_7_enterprise_with_sp1_x64_dvd_u_677651.iso"
fi
Along with other similarly shady links.
Look, IANAL, nor am I hooting and hollering for Microsoft's profits. But that README seems dishonest, any competent user should be suspicious of a "bobpony"-distributed Windows ISO.
Theres no easy solution there, directly linking windows ISOs is a direct violation of the TOS on the website, but there is permission to host the ISOs for your own reasons.
Agree that this should be in the documentation, but you can get into legal trouble if you directly link against microsoft.com in distributed code or binaries.
You can also get in legal trouble if you download and install a flagrantly pirated Windows ISO :)
AFAICT this software would solve all its legal problems[1] if it replaced these hard links to clearly unlawful websites with user variables, $URI_TO_WIN10ISO or something. The fact that the README is basically lying to its users makes things even worse. I would go so far as to call this malware.
[1] In the sense of "successfully foisting legal difficulties onto end users"
Ah - I misread your comment earlier, and I also didn't see that the other ISOs were hosted by Microsoft. In fact I misread most of this project because I was pre-emptively suspicious :) I guess the real problem is these older installations are in a bit of a grey area so I can see the value Bob Pony is actually providing here.
I'm pretty sure these ISOs are NOT modified though I am a bit skeptical of some of these sources. Editing my first comment to clarify that I misread this...
Why the hell are we trying shitty workarounds to dockerizing Windows? It's all dumb legal crap we have to work around... All the while, there's this Linux thing that just works.
And you usually don't actually need Windows. It's an application ON windows you need. So, try Linux/wine docker and dockerize it in WINE.
I think you are right, but I never made that particular point.
Nothing the client is doing is unlawful afaict; I would prefer it if it was documented and easy to swap out the URL.
FWIW I had this exact issue when using vagrant/packer and it was always painful because we couldn’t target windows ISOs easily but equally we didnt want to self-host them on a public repo because of the dubious legality and negative speculation as we’re discussing here.
Those bobpony ISOs could be backdoored even if they’re not breaking laws for the client user. Would be good to walk through the legal way to generate the download link.
It's extremely easy to swap out the URL of the ISO, you can put just any URL you want in the VERSION variable. This is also documented in the FAQ under "How do I install a custom image?".
If you dont provide an URL they are automaticly downloaded from the Microsoft servers using this script: https://github.com/ElliotKillick/Mido It generates a completely legal download link automaticly.
And those bobpony ISOs for versions that the above Mido script does not support are all unmodified retail versions. I checked their SHA256 checksums, and I would invite anyone with doubts to do the same.
Nor I insisted or implied anything. Just something from my memory through the years of similar problems of the dubious legality of tools to ease the day to day tasks for people.
> Would be good to walk through the legal way to generate the download link.
There is a proper way, just like you said: an easy way to inject http/s URI. Hosting a bunch of ISOs is a solved problem, objectively even easier than hosting a Docker registry.
It downloads all the ISOs from the official Microsoft servers for every recent version. For older versions like Win7/Vista/XP it is impossible to download them from Microsoft, because they are not available anymore on their servers.
So for those I had to use an alternative mirror (BobPony), but I checked all the SHA256 checksums to make sure they are unmodified retail versions. If someone does not trust it, they can check the checksums of the downloaded ISO themselves or just dont use this container for anything below Windows 8.1.
I found what you are referring to on line 76 of the assets/win7x64.xml answer file (under the “Key” directive).
So I googled the key to see if it was a widely circulated known cracked key I found.
It turned up on this site: https://www.windowsafg.com/keys.html which implies (strongly) that its a placeholder key that doesn't activate windows, they’re used for installation only.
I wish most of the software I use wouldn't need access to a GPU. Unfortunately, the only thing keeping me on Windows right now are graphics-related things (Adobe and friends).
I keep a Mac around for this sort of thing honestly. Otherwise I am on Linux and never looking back unless Microsoft makes a flavor of Windows for people who dont want a zillion telemetry and invasive features. Just not gonna happen any time soon.
I think that would have helped me the other day. I needed to debug a PWA on safari and i don't own any apple products. So i downloaded a windows VM machine and installed safari on it. It worked out but it was a pain.
You'd be better off testing against something more recent if you wanted any useful information about bugs happening on modern user devices. Safari isn't a greenfield release-every-two-weeks browser, but they have major annual updates and have been known to regularly add features in point releases between major versions, it's changed quite a lot since the last Windows Safari release a decade ago or more.
You can get much more recent Safari (and iOS simulator Safari) releases through macOS virtualization, https://github.com/sickcodes/Docker-OSX though this skirts some Apple EULAs. If you want desktop Webkit rendering and JS interpreter parity, https://webkit.org/downloads/ also offers several Linux webkit browser options that would also likely be more accurate than Safari v5.
No one will (should) ever expose /dev/kvm to containers in production.