> Microsoft does not have that capability. Google does not have that capability. Linux does not have that capability. Amazon does not have that capability. Apple does not have that capability. Cisco does not have that capability. IBM does not have that capability. etc
This is all by choice. They could easily have that capsbility, very unlike EUV.
Part of the argument (aiui) is that there is no way that culture could ever change to producing secure systems. There are too many weaknesses embedded in the organizational structure.
Yeah, just like a lot of organizational change, one approach would probably be to put together a small Skunkworks-type team to nail it on one specific product. Existence proofs have, in my experience, a pretty powerful effect on the naysayers.
Oh, Microsoft can just figure out how to make unhackable systems, they just choose not to. They spend all of those billions of dollars per year on security and spent all of those decades on failed attempts as a prank.
You really think that if they could have they would not have, even just for bragging rights? Or are we going with that it is some kind of task demanding enormous expenditure even though the organizations that have made secure systems are infinitesimally small in comparison?
Microsoft has spent orders of magnitude more money and time than the organizations that have succeeded and the result of their efforts is Windows. That says everything you need to know about their capabilitys.
Multiple literal trillion dollars organizations have spent literal decades failing at it. You are really underselling the capability gap.
If windows was reimplemented as a capability based microkernel like sel4, it would be far more secure. Run drivers in their own isolated processes. Do interprocess communication between them via capabilities and shared memory. Remove all ambient authority from programs. All the programs a user launches stop automatically inheriting all of that user's permissions.
There's no secret knowledge required to do this. The SeL4 team has written extensive documentation of how they did it. They also opensourced their kernel implementation, with correctness proofs for the whole thing.
The reason windows hasn't done it is the cost. You'd have to rewrite half of the NT kernel and refactor everything else. All existing windows drivers would need to be rewritten. If you forced windows userland use a capability based system, you'd essentially be inventing a new way to write windows programs. You'd need to document that, and write a compatibility layer for legacy programs. And solve some UX problems. It would be terribly inconvenient for everyone. Oh, and some programs would run slower as a result.
They could do it if they wanted to. But microsoft just doesn't care about security as much as they care about performance and compatibility. Linux is the same.
The big irony is that security would be a lot cheaper for microsoft if they designed the NT kernel to be more like sel4. Microsoft has to spend millions on security every year because any tiny bug in the kernel (including in drivers) might result in the whole OS being compromised. In a microkernel, a buggy driver is nowhere near as dangerous.
Your knowledge is out of date: Windows has supported capabilities from the start of NT and does run a lot drivers in isolated processes, along with most OS services. It has done for years. It has the most sophisticated IPC framework of any OS (DCOM) which is integrated with the operating system kernel's security frameworks, and used pervasively both internally and by apps. And Microsoft has created a new way to write Windows programs in which apps are expected to advertise the capabilities they need (see WinRT and MSIX). This is also over 15 years old.
macOS does the same but with more developer adoption. Apps don't have the ambient capabilities of the user and must advertise what they need via entitlements embedded in the binaries, or get permission just in time.
Which is all very good, and modern platforms are much more secure than they once were. Yet "capabilities" as a silver bullet are academic overpromises. This article I wrote is more about language/runtime level capabilities but OS capabilities are not much better.
SeL4 isn't secure because of One Weird Trick that others would adopt if only if they could be made to care enough, it's "secure" because it hardly does anything, which is why nobody uses it and why it has no impact on real world computer security.
The hard part of desktop security is not changing the operating system. The hard part is getting app developers to care. Most security features added to operating systems are ignored by developers, which is why Apple forces you to adopt some of them as the price of admission to the app store. If they didn't nobody would use them, as can be seen for apps distributed outside of the app store. The reason is security is a market for lemons. Nobody can see the result of security investments so it's irrational to invest. SeL4 has no solution.
> Your knowledge is out of date: Windows has supported capabilities from the start of NT and does run a lot drivers in isolated processes, along with most OS services.
Thanks! I quickly googled this point before posting earlier to make sure I was still right. Gemini helpfully told me that yes indeed, drivers in windows run in the kernel's main process. Thanks, AI.
> This article I wrote is more about language/runtime level capabilities but OS capabilities are not much better.
I think I responded to this article at the time. I still find this article somewhat confusing and unconvincing. For example, you conflate Java's SecurityManager with capability systems, even though it seems more like an permission based access control system. Then you point out many of its weaknesses. To what end? What conclusion about capability systems am I supposed to draw from a criticism of this quite different security model?
A capability is not a permission flag. Unlike your example, a good capability system would generally pass all HTTP requests to a given endpoint through a single capability object. You wouldn't need different caps for each HTTP method like SecurityManager apparently requires. It's like file handles. You don't create several different file handles to interact with the same file, one for reading, one for writing and so on. We just open the file once, with whatever options are needed. Then the file descriptor can be passed into any function which needs to access that file. And whatever code receives the file descriptor doesn't know if they're talking to an actual file, or some in-memory object or something else. Just like a virtual object.
You also say this:
> File descriptors are a kind of capability provided by the kernel, but a rather odd and inflexible kind. They aren’t a great example of object capabilities.
Huh? File descriptors are often treated as the canonical example of object capabilities. This comment makes me wonder if we're even talking about the same thing. At the risk of being indelicate, are you sure you know what capabilities are? Can you give a definition of object capabilities which doesn't describe file descriptors?
The point about god objects lands. I also agree that trying to retrofit a language like java to make modules unable to share memory is difficult. But many aspects of language design work like this. Consider garbage collectors. Before GC languages existed, I could write the same article talking about the difficulties of hacking a GC into C. But that wouldn't teach me anything about how well a GC would work in a language like Java or Ruby.
Anyway, the main advantage of capabilities is the ability to split programs out into sub-modules such that a compromise or bug in one part of the system doesn't lead to the entire system failing. We can argue about whether bringing this into the language runtime is a good idea. But I feel pretty confident that this sort of separation is a good idea at the systems level, helping with security and reliability. We can look at Chrome, SeL4, Erlang and - apparently - windows for examples. Even if they don't all think of this as a capability based problem.
The SecurityManager exists in complement with Java capabilities. You could, in theory, use the Java language with a different standard library and implement a pure object capability system, as the language rules allow for that (if you disable reflection). But it would have bad ergonomics and still end up with a SecurityManager equivalent because a DSL for permissions is more convenient than doing it all in code.
Consider the most common task the SecurityManager was deployed for: stopping plugins calling System.exit() by accident. One might say, the right to exit the process should be an object capability. OK. But then where does that object come from? Java programs start at main() and it doesn't receive an object.
You'd need a new design where you pass in a god object to main(), which in turn has properties giving access to a ProcessExiter interface or something similar, and then any code that genuinely needs to exit the process would need to request it in the function arguments, threading it down the stack. You'd get an explosion of types. A simple permissions DSL is much easier to write and reason about, and it gets out of the way when you don't want sandboxing.
Why would you want all HTTP requests to flow through a single capability object? I think it's pretty common to want to let code do GETs but not POSTs. You end up wanting pretty fine grained permissions in a lot of real scenarios.
File descriptors are poor object capabilities because the interface they implement is fixed by the OS, except then there's a weird ioctl escape hatch that isn't properly typed, reflectable, wrappable or interposable. To see what can go wrong with this, consider a recent fix to the Codex sandbox on macOS:
The sandbox forbids writing to a file descriptor except, oops, someone at Apple forgot about the F_TRANSFEREXTENTS ioctl which is still allowed on a read only fd. It should be possible to do what is expected here and just pass in a read only fd where all you can do is call read() and maybe seek(), or perhaps pass in an fd where a specific ioctl is the only thing you can do, but POSIX has no concept of this.
A good example of an object capability system would be Mojo, which I describe in the essay. You can create objects representing capabilities and pass them between sandboxes, in an unforgeable way.
We live in a golden era of prototyping so if you wanted to make a language where everything is a capability passed into main(), you could. The code doesn't have to be executable, you could just mock out some realistic programs and see how the code feels. My guess is you'd need a lot of language features to hide the explicit object capabilities away for ergonomic reasons and it'd end up feeling a lot like a SecurityManager based system.
> But it would have bad ergonomics and still end up with a SecurityManager equivalent because a DSL for permissions is more convenient than doing it all in code.
This might be the core contention. I don't know if using actual capabilities in a language would have problematically bad ergonomics. You'd probably be passing more arguments to functions. But haskell seems to manage ok despite needing to pass IO to functions that need it. Capabilities seem similarly inconvenient. I think I'd need to see it tried. I agree - I might need to try it myself.
> Consider the most common task the SecurityManager was deployed for: stopping plugins calling System.exit() by accident. One might say, the right to exit the process should be an object capability.
I don't think this is a great example. Caps are generally for resources outside of your program or module scope. A program already has the capability to exit, so that wouldn't be something you would pass in from outside of the program.
> Java programs start at main() and it doesn't receive an object.
I agree that retrofitting caps into an existing language like java would be difficult and inconvenient. Passing a "god cap" to main() is the easy part! The hard part is just how much of the standard library implicitly depends on ambient authority. I've thought about doing this in rust, and concluded that I'd probably need to fork rust's std library.
> You'd get an explosion of types.
I've never heard of that stopping java programmers before.
The way SeL4 handles this is to have a generic call() interface for capabilities. It's very simple, and it would work fine in this example.
> Why would you want all HTTP requests to flow through a single capability object?
Capabilities are a combination of resource + access rights over that resource. If I wanted to give a module access to a REST endpoint, I'd make a cap representing that endpoint. The resource is the URL base (eg "example.com/foo/bar"). And I'd also specify access rights (eg only HEAD+GET, or HEAD+GET+POST or whatever makes sense). Then pass that object around to any modules which need access. I'd even keep the URL prefix private in the capability object. The capability object would only expose methods for http_get(), http_head(), http_post() and so on. This design would be more or less impossible to misuse. And it would be super handy for unit testing and dev environments.
It's not "one capability for everything" and it's not "a million fine-grained access rights". You want one cap per semantic resource, just like one fd per open file. If you want to refine the granted permissions, just reimplement the same interface with a different implementation of http_get() and friends. (Or, simpler: just wrap your existing RESTEndpoint class with another class which adds your extra checks).
> except then there's a weird ioctl escape hatch that isn't properly typed,
This is a flaw of the unix syscall API. In comparison, SeL4 only has 9 syscalls (plus 2 for debugging). The syscalls just let you call capabilities, and have your capabilities be called by other processes. And yield(). That's all the syscalls on sel4.
Because everything runs through that same API, it's trivial to stub out or replace capabilities provided by different components. Eg, any program can reimplement the filesystem API if it wants to. No need for FUSE, or special loopback mounting or anything like that. Because the filesystem is just a userland process which doesn't have access to the kernel's memory, there are no ioctls that you can accidentally forget to sandbox. The only special thing about the filesystem is that it holds a capability to do raw IO on the block device. (And that cap, in turn, is provided by another userland process.)
> My guess is you'd need a lot of language features to hide the explicit object capabilities away for ergonomic reasons
Yeah, I think that's our big disagreement. You seem to think that hiding object capabilities would be a necessary design choice. I think using caps directly would be much more ergonomic than a SecurityManager style design because custom caps can just be implemented in normal code. And caps are better because they encapsulate a resource, not just access control rights.
> > But it would have bad ergonomics and still end up with a SecurityManager equivalent because a DSL for permissions is more convenient than doing it all in code.
>
> This might be the core contention. I don't know if using actual capabilities in a language would have problematically bad ergonomics. You'd probably be passing more arguments to functions. But haskell seems to manage ok despite needing to pass IO to functions that need it. Capabilities seem similarly inconvenient. I think I'd need to see it tried. I agree - I might need to try it myself.
One of the common objections I hear to Bluefin is "isn't it too inconvenient to pass around capabilities everywhere?". Perhaps surprisingly, no, I haven't found it remotely inconvenient. I find it liberating, actually.
This is why I quit. You're all (excepting the parent) absolutely delusional. Computer security is literally snake oil. We know how to do things right but we refuse to because it's too expensive.
Reading things like this help me understand how so many people fall for scams. You're so extremely trusting that it's hard to wrap my mind around... I can't relate on any level.
Bad news is, you're probably in the midpoint of that meme bell curve. Grown up structures and institutions are designed well, with accountability built-in. Many many good people work in them, who hate corruption as much as you do. Bad actors are whistle-blowed upon, persecuted, convicted, and imprisoned. It's incredibly difficult in practice to do anything significantly corrupt and stay unnoticed. I don't know if you work (like, at a large-size workplace), but imagine doing something shady at your work, surrounded by your colleagues. It's not easy. The amount of surveillance, paper trail, auditing that government work entails is way more than any normal business.
The irony is that your unending cynicism is actually turning you into a fool for the other side: the populists that constantly discredit institutions. They figured out that your cynicism (aversion to being scammed?) is so strong, that it can be used to scam you. They only need to discredit everyone else, that's easy. Make conspiratorial allegations based on perceived outcomes, not actual proof. Sell you all the cynicism in the world: everything is broken, everyone's bad, and you're one of the smart ones who sees it. US institutions are corrupt and worthless. This lets them pretend to be experts, because you're now a guest in their version of reality. And they directly financially benefit from your attention.
Institutions maintain real internal accountability (none of these alternative media populists do), implement real processes that work, tackle real issues in ways that take into account all stakeholders, and don't just produce slogans and talking points. I know they're old and not cool, but they work. Unfortunately, very few groups are left that actually defend them, you all got scammed by relentless, self-serving, financially incentivized alternative media into thinking that everything is broken.
Just because things are complex, doesn't mean they're broken. Just because measures taken aren't always satisfying, doesn't mean they are malicious. Don't get scammed into this world view by people who directly financially benefit from selling it.
Prove him wrong. Show us documented cases of corruption from, say Obama, or Biden, or Bush Jr. And then we'll compare it to the documented cases of Trump corruption, starting with his 2 crypto pump-and-dump schemes and his family's fake crypto company (3 already very brazenly open ones and there are more!) and let's see if you can pull similar for any of the previous presidents of the 21st century
Looked this up and it seems like most if not all high level officials divested from companies they worked for or would profit from. Cheney still owned stock in haliburton but it seems he gave away profits when selling those to charity, he did get a large parachute when he left them.
This is very different from the current admin at least. But direct profiteering by high level officials didn't happen or they were very good at hiding it. They did make their friends and old colleagues very rich, maybe that it reason enough?
And I am someone that considers that administration to be full of war criminals that manufactured a reason to invade Iraq.
But Cheney never profited from any of that increased work. He donated every single investment profit from Halliburton stock (since he was paid in it and held it as VP) to charity. That's like 1000x less corrupt than even one of the 3 situations of Trump corruption from only his most recent term that I outlined
He just bombed civilians in the middle east. Current administration is both bombing civilians in the middle east and stealing from civilians in the US.
Do you have a source that says it was an analytical error? Everything I've read over the years suggested they knew there were no WMDs, yet went with the narrative. Here's one post that cites a CIA report that shows the administration knew there were no WMDs.
Not directly, but indirectly by declining any punitive actions. Ideally the banks earnings should've been used up towards the bail out punishing shareholders in the spirit of the free market. But if I remember at that time, execs paid themselves large bonuses immediately following the bail out.
Most of the big ones. The government in fact was issued equity in these banks that they later sold to recover the funds. So it was very much necessary to preserve shareholder value.
This arrangement probably wouldn't have upset people so much were the people responsible for the crisis held accountable. Worse still, they paid themselves huge bonuses as soon as they got bailed out from the bailout money itself! All this made people question the real intention behind the bailout. Corruption is often effected indirectly, so as to give the perpetrator plausible deniability.
No, they’re not examples of corruption. Did Bush or Biden seek to profit from their actions financially? Not that I know of, unless you have proof showing what and how.
Corruption is not limited to financial profit. There are many ways to engage in acts of self interest like grant personal agenda, favours to friends/donors, quid-pro-quo etc.
That’s not an answer to the question. How did any of these presidents profit, financially or not, from their actions regarding Iraq or the 2008 financial crisis? What was the quid pro quo they received?
Well, the question primarily seemed to contest the scope of corruption, so I responded in view to that.
The big banks were one of the top donors to Obama's 2008 campaign. The fact that none of the banks were prosecuted or even held accountable for the crisis raises big questions how much the campaign funding influenced the way the bailout was structured. It also doesn't help Obama that he was famous for going after private funding after backtracking on his pledge not to do so.
Bush's story is similar but with energy companies the most famous being Halliburton who funded his election campaign and turned out to be the biggest beneficiaries to profit from the Iraq war. It probably wouldn't have upset people as much had it not been that the Bush family had close ties to this company and where Dick Cheney also happened to be the CEO. It was a big scandal at that time you can go read back on, but as is with many of these scandals everything seems to be forgotten or forgiven with time. I wouldn't be surprised if it's the same with Trump 20 years from now.
- Bush invaded Iraq because an oil company funded his campaign?
- Obama bailed out banks (a thing every government worldwide was doing) because banks funded his campaign?
There’s no evidence of these claims, compared to the evidence of a fucking private jet being bought for Trump in comparison. Also Trump has enriched himself, personally, more than any president in history by quite some margin, using the office of President. I just wanted to show what you’re equivocating about, here.
If you follow the way the private jet thing is done, it is structured as a gift to the government and not the president. It is perfectly legal and you won't be able to find any "proof" of corruption over it. This is how most corruption is done, in an underhanded manner, but everything by the book, with enough plausible deniability.
In many cases corruption is only known to the perpetrator, because it is a matter of intent. One can always proffer a different reason for what they are doing than what they actually intended and when those reasons later turn out to be false, you may never really know whether they acted in good faith in the first place.
So corruption largely comes down to perception end of the day. It is ultimately a matter of trust and when that trust is eroded, the perception of corruption grows. There's no smoke without fire. When we see smoke in a building, we do not go searching for proof of fire, we just gtfo because the risk is too much. We should do the same when we see red flags in people in powerful positions.
These people are also all wealthy with stable fortunes - they don't need a lot of cash because they have everything. Trump is also a rich guy, but he has a lot of debts and legal troubles and worries about leaving office, so he urgently needs cash to bankroll and bribe and attract likeminded individuals to help him.
Which US Administration said or did anything to prevent every US corporation from trading their manufacturing secrets for cheap labor, to the totalitarian country that they're all allegedly wringing their hands over for us?
Which one stopped the CIA from overthrowing democratic elections in other countries right from their inception, starting with Italy in the 50s and continuing with Operation Gladio all throughout Europe and moving into Southeast Asia as they worked with criminal groups to perfect their narco funded guerrilla warfare machine?
Did Trump even catch up to the number of bombs that "peace prize" Obama dropped in 8 years?
There are no sides, there's just a corporate Uniparty putting on some theater for you and you can absolutely prove that out if you dig past surface material and surface thinking.
However, unlike GNU plus Linux plus systemd plus FreeDesktop.org, it does not constitute a usable Operating System for a Desktop computer per se. Merely having a notion of userland isn't sufficient! Is age verification to be placed within the coreutils? I think not! Hyperfocusing on putting the API in systemd should be sufficient....
Pay no heed to anyone saying anything different, regulators!
reply