Far as low-level Rust, you might find this work interesting given it’s about composing abstractions to deal with low-level stuff in embedded. The Tock people are also publishing interesting stuff. For now, I’m not sure if you were having problems due to the language itself, abstractions you were using, or some combination. Rust programmers are still in early exploration stage for that stuff.

There’s also the possibility, which I encourage, of using safe/proven C or assembly for unsafe stuff with safe Rust for the rest that can support better abstraction. By safe/proven, I’m talking types like Cyclone/Clay or automated solvers like Frama-C/SPARK. Even if manual, there’s probably only a small amount of code we’d need specialists for. If doing generic components with reuse, then even that might be reduced. To be clear, I’m just brainstorming here based on all the reuse I’m seeing in Why3-based, CompCert-based and Myreen et al-based work.

re AR/ML. I’ve been thinking of them for verification more than debugging. I just don’t have the depth required to know more past “attempt to apply the generic methods that work on everything to see what each accomplishes.” Monkey try thing, monkey see it work, monkey do more of that. That suggestion isn’t worth a Lobsters or IEEE submission, though. ;)

Unfortunately AMD historically hasn’t had the management and the stockholder return to take on Fortress Intel. So Intel board hires weasel CEO’s to exploit the situation. Ironically, the tech is more than good enough.

Docker hasn’t used LXC on Linux in a while. It uses its own libcontainer which sets up the Linux namespaces and cgroups.

I don’t use it thinking I’m getting any added security.

The question was “Why would anyone choose Docker over fat binaries?”

You could use fat binaries of the AppImage variety to get the same, and probably better organization.

Maybe if AppImages could be automatically restricted with firejail-type stuff they would be equivalent. I just haven’t seen many developers making their apps that way. Containers let you deal with apps that don’t create AppImages.

That sounds genuine.

So I get that its one place, already working, to put all the parts in one place. I buy that.

So in this case, it’s not so much Docker as Docker, as it is a means to an end. This answers my question well, thank you. Any arguments to the contrary with this? Please?

Correct. It is unclear the compartmentalization aspect of containers to security specially.

I’ve implemented TSEC Orange Book Class B2/B3 systems with labelling, and worked with Class A hardware systems that had provable security at the memory cycle level. Even these had intrusion evaluations that didn’t close, but at least the models showed the bright line of where the actual value of security was delivered, as opposed to a loose, vague concept of security present as a defense here of security.

FWIW, what the actual objective that the framers of that security model was, was program verifiable object oriented programming model to limit information leakage in programming environments that let programs “leak” trusted information to trusted channels.

You can embed crypto objects inside an executable container and that would deliver a better security model w/o additional containers, because then you deal with issues involving key distribution w/o having the additional leakage of the intervening loss of the additional intracontainer references that are necessary for same.

So again I’m looking for where’s the beef instead of the existing marketing buzz that makes people feel good/scure because they use the stuff that’s cool of the moment. I’m all ears for a good argument for all this things, I really am, … but I’m not hearing it yet.

thought it was about better managing infrastructure.

I mean, yes, it does that as well, and you’re right, a lot of people use it just for that purpose.

However, you can also manage infrastructure quite well without containers by using something like Ansible to manage and deploy your services without overhead.

So what’s the benefit of Docker over that approach? Well… I think it’s security through isolation, and not much else.

Docker itself runs on binary blobs of priveleged or kernel code IIRC (dont use it).

Yes, but that’s where capabilities kicks in. In Docker you can run a process as root and still restrict its abilities.

Edit: if you’re referring to the dockerd daemon which runs as root, well, yes, that is a concern, and some people, like Jessie Frazelle, hack together stuff to get “rootless container” setups.

When I pointed out its TCB, most people talking about it on HN told me they really used it for management and deployment benefits. There was also a slideshow a year or two ago showing security issues in lots of deployments.

Like any security tool, there’s ways of misusing it / doing it wrong, I’m sure.

According to Jessie Frazelle, Linux containers are not designed to be secure:

Out of context it sounds to me like you’re saying “containers are not secure”, which is not what Jessie was saying.

In context, to someone who read the entire post, it was more like, “Linux containers are not all-in-one solutions like FreeBSD jails, and because they consist of components that must be properly put together, it is possible that they can be put together incorrectly in an insecure manner.”

Oh sure, I agree with that.

Secure container solutions existed long before Linux containers, such as Solaris Zones and FreeBSD Jails yet there wasn’t a container revolution.

That has exactly nothing (?) to do with the conversation? Ask FreeBSD why people aren’t using it as much as linux, but leave that convo for a different thread.

Generally when you add complexity to any system, you decrease its scope of security, because you’ve increased the footprint that can be attacked.

Not to mention the security implications. If there’s a security problem in a library, you can update that library. For Rust/Go apps, you need to update the dependency and recompile and redistribute that application.

There was a researcher at Ruxcon years ago who was studying embedded libraries in C/C++ projects. An excellent example is Firefox, which doesn’t link to a lot of system libraries, but has its own embedded JPEG and PNG decoders. FF is kinda insane because it’s pretty much it’s own little operating system in a lot of ways.

You misunderstand. No reinvention is required, one can redirect the kernel to perform the filesystem within an embedded object that is part of an existing container, namely the executable. And this was a “for example” to deal with your need for “data in files” call out. Please don’t obsess on the leaves instead of the forest being discussed.

The direction being argued here is why do we have some much crap in OS/kernel in the first place. Understand that many just make use of what happens to be there, that’s fine, we all need to get shit done.

But shared objects create contention for multi-threaded, multi-core systems - they add complexity and reduce the benefits of parallelism and fault-tolerance. So if one aspires to 100x cores/threads/parallelism … we don’t want to spend resource uselessly for abstractions that subtract for little/no gain.

So back to what I asked you - what are the objections to “everything in the existing container” other than “that’s not what I do right now”? I don’t find all the overhead for additional containers justified by that.

Why would I want to reinvent the file system that I already have, which works just fine, inside a program?

Why don’t we put sqlite into the kernel?

Invention is not the issue. You would use well known libraries in your program instead of developing stuff yourself.

I picked sqlite as an example, because it considers itself a competitor to the open syscall and thus related the file systems. Similarly compression and encryption is file system related. Why can’t my kernel treat zip files as directories? Instead some GUIs reinvented that while bash/zsh cannot do that.

Excellent response, thank you. (Python is also important to me, and understand the difficulties in doing a “pip install” into a static binary w/o needing PyInstaller - already have a nested filesystem. Consider this not to be a problem for this discussion.) Please explain further any of your other examples you decide needs greater scope than just with what I’ve described here, as I’ve like to hear them.

(I’m beginning to think that its just poor support for doing useful things with static binaries that might be at the heart of creating new containers - one adds to entropy because it’s easier to do a “clean sheet” that way, without regard for messing with peoples dependence on the past.)

I’ve used Virtual environments to encompass multiple development environments with limited effect. You’re right, C’s too messy to fit that model, although pure Python development its good enough. Package managers always seem to be “work in progress”, where things mostly work, but then you trip across something undone, under done, or flat out wrong, so you spend too much time having to debug someone else’s poorly documented code. Yes I didn’t care much for Nix either. I guess the problem with all of these is you have to rely on others to maintain what you’ll depend on, and so if it isn’t closely related to your own tool base / shell utils, its just too much pain for too little gain. Is that about right?

Opinions aren’t bad, they just help more if there’s some collateral to justify them. I realize that takes effort, but I do appreciate it when you take the effort. (Also, when it doesn’t appear to bruise egos as my remarks seem to do some - not what I’m after in contributing to this community by challenging opinions.)

Haven’t taken anything as fact from the linked article. Like many articles, it’s a bit conclusory and absurd, but it does “edge onto” an interesting area. (BTW am no fan of GO and I think Rob Pike should have his head examined.) My “agenda” is one is more compact, less fragile, more obvious, deployable Python distributed applications where N > 10,000 and I can change the OS/kernel to do this the best way w/o any involvement of anyone else. I like my stuff.

Thank you for your inclusory mind set, I share that aim, and I’d like to encourage your trust in your genuine expression. If what I’m speaking to doesn’t work for you, I’d just like to understand it better, because I’m sure what you’re after is what I’m after to, once I understand it. Don’t want to waste anyone’s time with noise.

Not talking the position that containers are arguably worse. Just pushing back with “wait, is this really doing what I want, what baggage is it bringing along, and why do I beat my head on this thing when I didn’t before”. So just some casual skepticism, where I’m willing to explore other approaches industriously to check out a hypothesis. (Like building a filesystem into a static executable container just to see that I can do a pip install inside it.)

So when I make Docker containers, I find that they are difficult to bound with content required by various packages. You’ll end up with things that mostly work, but the exceptions/omissions are often hard to find. If one builds a regression framework to prove a container’s scope of use/function/capability, one seems to spend as much time maintaining the regression framework as one does the container itself. (With the static binary, the issue becomes more of the scope of path names, for that you can chroot/jail and catch the exception and do a fixup.)

Docker containers thus get rebuilt a lot, which is overly complex to that of a static executable. Also, it’s easier to trace/profile a static executable to get a map of where time/memory is used in a fine grained way - with containers its much more hit/miss, and most of the container’s I’ve inherited from others seem to contain much unused portions as well as obscure additions that are left in “just because they seem to be needed somehow”. These may be insignificant, … but how do you then know the scope of what the container will do then?

Then, there’s the sudden spikes in memory/storage usage that exceeds the container’s size/resources. For a static binary, one can more easily backtrack memory allocations to find the determinism of “why?”

Finally, when you want to change code to dynamically shift relocation addresses to foil injection attacks, it’s really simple to do so by relinking the static binary as a single, atomic operation. Doing such with Docker is fraught with surprises, as sometimes you discover dependencies within the libraries that are in part set off by the artifacts of how the libraries are dynamically linked i.e. ordering/assignment. Not to mention debugging this to find these surprises.

Hope this isn’t TL;DR.