Hey Simon, given it's you ... are you concerned about LLMs attempting to escape from within the confines of a Docker container or is this more about mitigating things like supply chain attacks?
I'm concerned about prompt injection attacks telling the LLM how to escape the Docker container.
You can almost think of a prompt injection attack as a supply chain attack - but regular supply chain attacks are a concern too, what if an LLM installs a new version of an NPM package that turns out to have been deliberately infected with malware that can escape a container?
When you use docker you can have full control over the networking layer already.
As you can bound it's networking to another container that will act as proxy/filter. How WASM offer that?
With reverse proxy you can log requests, or filter them if needed, restrict the allowed domains, do packet inspection if you want to go crazy mode.
And if an actor is able to tailor fit a prompt to escape docker, I think you have bigger issues in your supply chain.
I feel this wasm is bad solution. What it brings a VM or docker can't do?
And escaping a docker container is not that simple, require a lot of heavy lifting and not always possible.
Aside from my worries about container escape, my main problem with Docker is the overhead of setting it up.
I want to build software that regular users can install on their own machines. Telling them they have to install Docker first is a huge piece of friction that I would rather avoid!
The lack of network support for WASM fits my needs very well. I don't want users running untrusted code which participates in DDoS attacks, for example.
You have the same lack of network support with cgroups containers if you configure them properly. It isn't as if it's connected and filtered out, but as though it's disconnected. You can have it configured in such a way that it has network support but that it's filtered out with iptables, but that does seem more dangerous, though in practice that isn't where the escapes are coming from. A network namespace can be left empty, without network interfaces, and a process made to use the empty namespace. That way there isn't any traffic flowing from an interface to be checked against iptables rules.
I think that threat is generally overblown in these discussions. Yes, container escape is less difficult than VM escape, but it still requires major kernel 0day to do; it is by no means easy to accomplish. Doubly so if you have some decent hygiene and don't run anything as root or anything else dumb.
When was the last time we have heard container escape actually happening?
Just because you haven't heard of it doesn't mean the risk isn't real.
It's probably better to make some kind of risk assessment and decide whether you're willing to accept this risk for your users / business. And what you can do to mitigate this risk. The truth is the risk is always there and gets smaller as you add several isolation mechanisms to make it insignificant.
I think you meant “container escape is not as difficult as VM escape.”
A malicious workload doesn’t need to be root inside the container, the attack surface is the shared linux kernel.
Not allowing root in a container might mitigate a container getting root access outside of a namespace. But if an escape succeeds the attacker could leverage yet another privilege escalation mechanism to go from non-root to root
Better not rely on unprivileged containers to save you. The problem is:
Breaking out of a VM requires a hypervisor vulnerability, which are rare.
Breaking out of a shared-kernel container requires a kernel syscall vulnerability, which are common. The syscall attack surface is huge, and much of it is exploitable even by unprivileged processes.
They both can be highly unescapable. The podman community is smaller but it's more focused on solving technical problems than docker is at this point, which is trying to increase subscription revenue. I have gotten a configuration for running something in isolation that I'm happy with in podman, and while I think I could do exactly the same thing in Docker, it seems simpler in podman to me.
Apologies for repeating myself all over this part of the thread, but the vulnerabilities here are something that Podman and Docker can't really do anything about as long as they're sharing a kernel between containers.
If you're going to make containers hard to escape, you have to host them under a hypervisor that keeps them apart. Firecracker was invented for this. If Docker could be made unescapable on its own, AWS wouldn't need to run their container workloads under Firecracker.
This same, not especially informative content is being linked to again and again in this thread. If container escapes are so common, why has nobody linked to any of them rather than a comment saying "There are lots" from 3 years ago?
Perspective is everything, I guess. You look at that three year old comment and think it's not particularly informative. I look at that comment and see an experienced infosec pro at Fly.io, who runs billions of container workloads and doesn't trust the cgroups+namespaces security boundary enough so goes to the trouble of running Firecracker instead. (There are other reasons they landed there, but the security angle's part of it.)
Anyway if you want some links, here are a few. If you want more, I'm sure you can find 'em.
Some are covered off by good container deployment hygiene and reducing privilege, but from my POV it looks like the container devs are plugging their fingers in a barrel that keeps springing new leaks.
(To be fair, modern Docker's a lot better than it used to be. If you run your container unprivileged and don't give it extra capabilities and don't change syscall filters or MAC policies, you've closed off quite a bit of the attack surface, though far from all of it.)
But keep in mind that shared-kernel containers are only as secure as the kernel, and today's secure kernel syscall can turn insecure tomorrow as the kernel evolves. There are other solutions to that (look into gVisor and ask yourself why Google went to the trouble to make it -- and the answer is not "because Docker's security mechanisms are good enough"), but if you want peace of mind I believe it's better to sidestep the whole issue by using a hypervisor that's smaller and much more auditable than a whole Linux kernel shared across many containers.
I mean docker runs in sudo privileges for the most part, yes I know that docker can run rootless too but podman does it out of the box.
So if your docker container gets vulnerable and it can somehow break through a container, I think that with default sudo docker, you might get sudo privileges whereas in default podman, you would be having it as a user run executable and might need another zero day or smth to have sudo privilege y'know?
Interesting because the repo only lists a MIT license, with no mention of those requirements. IANAL but those license terms don't seem to be anywhere in the software repository.
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction...
I used Cline+Claude 3.7 Sonnet for the initial draft of this LLVM PR. There's a lot of handholding and the final version was much different than the original.
Why does this keep happening? Do people not understand the implications choosing an open source license.in the first place? There are a million licenses, in fact you can just make your own one up! But when you choose a class of license the specifically allows commercial exploitation... you don't get to act wronged when it happens.
Two key reasons, they don't understand the implications, and many developers are cheapskates nowadays, they wouldn't have survived in old days until 2000's, where we paid for everything, or pirated it.
Somehow it feels great to be paid, to pay others for the tools, like in every other profession, not so much.
Yes but the quality difference was bigger. And there were big gaps, eg until OpenOffice there was no decent alternative for MS Office. Most SDKs and IDEs cost money too (like the big visual studio still does)
The license is still open source. There's only a branding requirement added. Not much unlike "you must retain this notice" in other open-source licenses, like the Apache license.
I frankly find LGPL more useful in cases like that, but it apparently does not work for some parties. Open-source + commercial licensing also looks like a good balance between keeping the community-developed code accessible to everyone, while allowing the parties who don't want to share to pay for the privilege.
That is my approach as well, downstream should get as much as they are willing to give upstream.
Nothing, then get nothing as well.
Pay the work of others, than freely charge as much as they feel like.
On my repos, the only stuff I have with ROCm licenses are forks from projects where the decision was not mine to begin with.
As time has proven, shareware and trials is a much better model if one intends to make a living from software, without having it lock behind SaaS walls, or hardware.
Even street performers got their work tools from somewhere and unless they were going around the scrap yard, it wasn't at zero cost most likely.
I think there's some selection bias. In my experience many folks that work on open source projects tend to lean more altruistic and good natured - so understanding the license doesn't mean expecting exploitation.
Its deliberate, use a permissive/pushover license to get adoption, then rugpull once you have the userbase who are relying on you, then bathe your VCs in cash.
You can't make such a claim without any backing. While undoubtedly it's the case for some, I strongly doubt everyone does it on purpose. It's just that orgs mature with time and realise their original naiveté.
Do you have any proof of that? Hell, are OpenWebUI even receiving VC funding?
Obviously, you will be able to find plenty of examples of things that don't work, and you probably have a bank app or some other thing that you need Google for, but alternatives do exist, and I'd argue that you can have a healthier, more productive, and more enjoyable experience if you can have all your needs met by software that isn't treating you as a product.
My opinion is you should use whatever works; I do. But try not to absolutely need software that you can't control.
As you say, due to banking, this works more or less depending on which country you live in.
Some countries have tied their banking to their phones, with apps that use SafetyNet to check how Googled you are.
Somehow corporations and nations have given sovereignty away for convenience and so you may need 2 phones: the google one and the good one, to properly be f-droid only.
I agree with you that most consumers probably do want things that are bad for them. I would at least be cautious of services provided by one of the companies with the most anti-trust lawsuits this century, I really don't think they're your friend.
It’s dangerous to assume so much as this about the thoughts of someone on comments, but let me offer a supporting opinion to the other point:
People like things to be consistent and reliable. When we’re talking about technology, they probably don’t know what specific coding or licensing or development practices lead to that, but they know that they don’t like it when something they use gets worse over time.
When things they use everyday change at the whim of one company that has full control, they don’t always like it. Having software that’s free to modify and distribute makes it so people will always have options and not depend on one company or another having the same opinions about what makes software good.
"Having software that’s free to modify and distribute makes it so people will always have options and not depend on one company or another having the same opinions about what makes software good"
Yeah its called android, company like samsung,xiaomi,huawei etc literally modify android and its come out of the box with the phone
are you saying that android without google is the answer since android is still google, saying you dont want google but still using android is not really live up to the opinion since google can change android core anyway
This isn’t about wanting or not wanting Google but wanting freedom. I don’t avoid Google completely, but I don’t want to be dependent on them. I always want to have free and open alternatives to what they provide.
The AOSP works for those different companies because it’s free to modify. Huawei had to move away from Android (still using parts) because Google services were not free or available to them. That was fine because at least the core parts remained free.
If the basic functions of life like paying for things don’t work without Google, it’s a problem. That’s bad for people and too much pressure for Google to do the right thing for people who have different needs.
Yeah, it's called hypocrisy. You want all the good things without the bad things, but they come with an associated cost. People are free to use anything other than Android or iOS; no one forces them to use Google services either.
Google is an objectively evil company, ever since they removed their “Don’t be evil” slogan. Android is, conceptually, a good idea. There is no “emotion” behind that statement, they themselves have said they are evil, and their actions regarding Android reflect that. It is not hypocrisy to desire that there be more good than bad in this world, and I urge you to read a dictionary.
Yeah its called "don't use android at all", its called hypocrisy when you still use android without the google service
same with IOS, I bet a lot people desire IOS on non iphone device but that not going to happen soon because Apple profit is from iphone sales
same with youtube, people dont like watching ads but youtube bussiness model is not going to survive without ads (who going to spend money if people can upload unlimited video on it for free???)
google benefit from android development cost because they can generating revenue because people can get use google service
its called BUSSINESS, there is no evil in doing bussiness. dont talk me about being right or evil when we talking at HN when most people want to create unlimited subscription for their service
It’s not hypocrisy to remove the cancer from my phone, tumors like Google Services exist to be removed. I use an Adblock, I download all the videos I like to personal storage after watching them on YouTube via a shared Indivious frontend me and my friends use (meaning Google takes the data hit twice), and I always fill up my GDrives. This way I can slowly do my part in removing evil from this world.
There is absolutely evil in doing business, unless you view things such as slavery as A-OK. And trust me, I fucking hate subscriptions and view those who fall to forcing them onto their users as less than scum. They are just as evil as Google or Apple are.
Before Google Play Services, updates were a big concern for Android. If Android N had the feature you wanted, but Verizon/Motorola only shipped N-1 for your Droid, you were out of luck. There were pie charts routinely tossed around showing which devices had which Android version numbers. You don't hear those concerns nearly as often anymore.
Makes me wonder what the tradeoffs/alternatives are. Maybe they could have still moved features to a Play Services-esque library but published the source for it. Considering we're commenting on a post about how developing in the open is too inconvenient for modern Google, the difference might have been moot.
Android is not any one thing and it was never open source. AOSP meanwhile is entirely open source, to the letter.
AOSP is a compromise, because device manufacturers don't want to share anything. Google effectively negotiated with device manufacturers to open source part of their software. Device manufacturers lose some of their secret features to competitors. In exchange, they don't have to develop those features themselves. App developers get a standard platform, which benefits everyone: users and manufacturers and app developers.
This is very much a win-win situation, because the alternative is that every manufacturer has their own proprietary system.
> This is very much a win-win situation, because the alternative is that every manufacturer has their own proprietary system.
No, it's a lose-lose situation. If we have 100 different mobile OS's it's a matter of time until a "good one" appears, and we get some sort of innovation in the space - be it from a technical perspective, from an UX perspective, or whatever.
Now we're all stuck with Android, where manufacturers can't really do anything interesting with their phones, users get an incredibly bloated, technically incompetent system, and all parties have to abide by Google's every whim.
Courts have ruled that compilation does not remove originality—the binary is still a transformation of an original, copyrighted work (the source code).
reply