Docker is a lot more than just an unprivileged user. In particular, it comes with a seccomp filter. A lot of LPEs are blocked by that filter. Docker is actually a quite decent security boundary - in this case the attackers did not attempt to subvert docker by attacking the kernel attack surface, they attacked a weak configuration via the docker socket being mounted.
The reason you don't use a "grown up VM" is because it's significantly more difficult. Which VM? Firecracker requires KVM and a guest operating system - so how are you getting things in and out in a way that doesn't violate security? That's real work.
gVisor is great and my recommendation, certainly, but the difference between "nothing" and "docker" is actually pretty huge imo.
> the difference between "nothing" and "docker" is actually pretty huge
You've got me there, but it's not really saying much.
Seccomp, for example, is nice, but... It blocks ~44 system calls, and leaves 300 plus exposed. Any memory corruption issue in those remaining calls remain wide open. So better than nothing? Absolutely, but it leads to a false sense of security. I know actual security researchers that intentionally run malware inside Docker and think they're safe. They're not.
Then we can talk about docker itself. It had something like 6 public CVE's related to full escapes last year. If your patch cycle takes 30 days then you spend about half the year with a full, public, escape known. Even if you patched those all on day one you spent most of the year vulnerable to one of the many Kernel vulns that it doesn't stop. On any given calendar day it's statistically likely there is at LEAST one way to escape publicly known and unpatched.
So, yeah. It beats nothing by a huge margin, but it's WORSE than nothing if you think it's safe to run arbitrary untrusted code in. That was never what it was for, it's just what people treat it as. It's not a VM, wasn't designed to be, and people need to stop pretending it is.
The solution is to do exactly what you suggest - separate access. In CI this is a matter of having your "build/test" jobs happen separately from your "deploy/publish" jobs.
The trickier part is dev environments, but ideally you take a similar approach. The place that devs do `npm install` should be isolated from, say, your browser / ssh keys etc.
Package manager support would be an amazing win here since you'd have an easier time managing the isolation but you can do this today.
That seems like the opposite. Why would someone with high market value stay in one place? 2 years is basically optimal - you vest 50%, maybe collect a promotion, do some good work and learn a lot, and then get to move on for another solid bump/ promotion and a new set of stocks.
I expect the people with low market value to be the ones sticking around labs for long periods of time, they don't have the option to move and they aren't getting poached.
> The harder question is what the architecture around the vulnerability should look like. The principle is to make exploitation harder for an attacker even when a bug exists, so that the gap between when a vulnerability is disclosed and when it is patched matters less. That means defenses that sit in front of the application and block the bug from being reached. It means designing the application so that a flaw in one part of the code cannot give an attacker access to other parts. It means being able to roll out a fix to every place the code is running at the same moment, rather than waiting on individual teams to deploy it.
> The hard problem identifies the in principle difficulty in explaining phenomenal consciousness, something not definable in terms of structure and function
Great, I'm a physicalist so uhhhh I reject this lol. I think you can define cognitive capabilities and phenomenal experience by reducing to structure and function. You're right that it's simple though.
I'm a physicalist as well. A commitment to physicalism doesn't force you to reject the hard problem. The hard problem doesn't entail that phenomenal consciousness is not grounded in physical structure and function. The hard problem is about what is needed to explain consciousness. Science typically involves defining some phenomena precisely in terms of structure and function, then giving a precise story about how some observed behavior captures the structure and function that defines the phenomena under question. For example, we define temperature by the height of mercury in a thermometer, then we mathematically derive the height of mercury given the average speed of molecules in the environment. Thus we successfully reduce temperature to average kinetic energy of molecules.
But the process of reduction starts by precisely defining the phenomena in terms of structure and function. If we are unable to give a precise definition that uncontroversially captures the target phenomena, then we cannot in principle give a scientific explanation of said phenomena. This is where we stand with consciousness. There is an in principle barrier to a transparent structural description of phenomenal consciousness. But this is an explanatory limit only. It doesn't necessitate some non-physical phenomena is involved. What we need are new concepts that can connect the phenomenal to the physical. But conceptual innovation is not something you get from more measurements and more data. This is what makes consciousness a philosophical problem.
I was rejecting your definition of the hard problem as it contains an assertion that a physicalist wouldn't accept.
Yes, reduction would be one very viable strategy. It doesn't require precisely defining the phenomenon in order for me to just say that it reduces based on the fact that reduction has been a successful approach for everything else in cognition.
> There is an in principle barrier to a transparent structural description of phenomenal consciousness.
Yeah this is what I reject. Why do you say that this is in principle a barrier? You're discussing it as an explanatory gap, not in principle.
The claim that you can't describe consciousness in principle is widely accepted by participants on all sides of the debate. Can you tell me what experiencing red is like to you such that someone who is red/green color blind will know what its like? Most people think not. Rather, phenomenal consciousness is something you must experience yourself. It just isn't something that one can learn descriptively. This is a premise of the hard problem and also the Mary's room thought experiment. People who reject the premise usually just reject phenomenal consciousness completely.
Interpreting the hard problem as an epistemological problem looks trivial. There's nothing extraordinary in ignorance. The way you describe it implies we have the hard problem of ultrasound too.
I think it's ontological problem: structural description ontologically misses unobservable ideal substance, so the challenge is to provide a principle that would make ideal substance unnecessary. If you don't think too much, ideal substance ontologically solves consciousness, and it's not obvious how mere structural description can live without it.
That's like saying that "water" is a philosophical invention and so if you accept that water is a thing then you've put it into a special category.
You can derive consciousness as a somewhat obvious conclusion of empirical study of behaviors, we have multiple fields of study that lay out cognitive function and criteria.
You could have said this every year for so many years about so many companies. If people will work for Palantir, they'll work for Facebook. Facebook could be a lot worse and I think a lot of their employees would stick around.
I guess a response at the industry level would be not hiring ex-FB people etc, treating it as a red flag.
You're confusing _evil_ with _cruel_. Palantir is the former, but from what I have heard they treat their employees well. They are attracting exactly the kind of people they want.
That's true and probably a kinda critical distinction here. Facebook is sort of making the bet that they can not only treat the world like shit but their direct employees too.
> The no-AI policy of the Zig compiler project is for the compiler, other projects can do whatever they want.
Well, presumably they want to contribute to the compiler. I know that you did not like those contributions, and that view seems entirely valid, but obviously "no AI" rules out their development model (by design, and you likely think that's good, and maybe it is!).
Not intending to defend the bun move, but obviously a project using Zig and also using AI might feel motivated to avoid Zig since they're ruled out as contributors.
The reason you don't use a "grown up VM" is because it's significantly more difficult. Which VM? Firecracker requires KVM and a guest operating system - so how are you getting things in and out in a way that doesn't violate security? That's real work.
gVisor is great and my recommendation, certainly, but the difference between "nothing" and "docker" is actually pretty huge imo.
reply