China hacked 22.1 million records of US government employees:
https://en.wikipedia.org/wiki/2015_Office_of_Personnel_Manag...
For example, do not hook your goddamn water or traffic or electricity infrastructure up to the goddamn Internet, and then, do fire the guy who suggested it.
The correct analogy for computer security is not locks and keys and doors and gates. It is a house in a floodplain. Your house will not survive the flood of it hits you. Do not store anything critical or irreplaceable in that house.
Does this answer your question?
/s
People flaunting their credentials in multiple languages, then sweating bullets and apologizing profusely when they see
int t = 4;
It might even help in figuring out whether Haskell would be a good fit. Something I couldn't do, as I do not know the language. Then again, it's not a question that really gets asked much in a corporate setting. Most things are just solved in a few popular languages, whether that makes the most sense or not.
I agree. The people who depend on chatbots to write their code for them won't have either of those skills though. They don't know (or are in the process of forgetting) how to code, and they're missing out on the opportunity to really learn the language by turning off their brain and letting a bot spoon-feed them code.
An LLM would only get in your way if you actually wanted to learn Haskell.
It’s abstractions all the way down and most people aren’t going to have an intimate understanding of every layer, and it’s not economically worth it for the vast majority to even try
LLMs just give you results (of highly variable quality) and if you lack a solid understanding of the language being used that result gets blindly accepted as valid (especially if it manages to 'do the thing' when you test it). Learning how to type a prompt is not the same as learning how to code or learning a programing language.
Huh? I wish…
Actually, if by “learning to code” you mean “writing good usable code”, my experience is that many people struggle to code. Especially when you consider planning a (human-level) complex project.
Maybe you don’t know those people. I work with them every day.
Claude hasn’t been around for a generation yet.
It’s a good thing that people are scared to hand write memory-unsafe languages. 50 years of exploitation has finally sunk in…
The calculus has certainly changed. Hacking is becoming even more frequent and… I’m not really sure what the equilibrium looks like.
It’s not really an option to stop using computers or networks. But it’s going to be way too expensive (or maybe even impossible) to secure even just critical systems.
Maybe banks and governments can secure themselves (and that’s a big IF) but it really feels like something fundamentally has to change.
Admiral Adama says otherwise.
Even just consider banks and e-commerce. They are hugely lucrative and making them even a tiny bit less accessible directly impacts their revenue. As an example, Amazon seeing that latency has a measurable effect on purchase behavior.
Maybe the military (fictional or otherwise) can go back to the ARPANET but most economic activity created by the internet cannot afford to disconnect
Even putting that aside, economic growth (like the growth e-commerce has provided) is generally positive for a population
In the real (fake?) world the toasters would shoot smart dust all over your crap that would assemble back on your circuits creating radios between all the different components. They were fighting an adversary that was far more advanced than them.
If there's too much security in the way, it seems to me that work becomes impossible.
Of course, by making it remotely operable, that one guy could be replaced with a guy in Russia who's job is to poison everyone.
If not a person you need more redundancies built in. Bigger tanks, multiple backup systems. When items start failing you need them to be shutoff in a timely manner. Water pumps at these facilities are in the 50-100k range. When it starts failing you want to know.
Think of it like driving a car and it starts making funny noises. The longer you wait to fix it the more it costs.
But more to the point, a modern water network has a huge number of nodes. If you can't centrally aggregate and control in a control room the costs and complexity explode, probably also the error rate.
Even if you demand a full air gap, the solution here can't be to get rid of computers or networks. They are much, much too valuable. Luckily industrial control is full of very low hanging fruits.
Like something that would work but not not scale would be one computer writing data to an updating qr code and another reading it. Surely something like that can be made (and probably already exists?) on the cable level?
Set up a monitor with the data values you need to monitor
Point a camera at that monitor.
Camera feed is remote accessible. Control software is not.
Want alarming? There's systems designed specifically to send texts or make phone calls when signaled electronically.
You can be very defensive and design any remote sensing controller to act as two systems - one management cpu only does data routing (no other connection than administrative tasks), sensor cpu works only with sensors. As bonus you can have management cpu act as active firewall.
Main problem it is necessary to have in house expertise (hw, fw and process knowing) which in making company lean are optimized first and outsourcing custom solutions suddenly too expensive.
Adding AI into this really is just changing it to how much money your adversary is willing to spend to break in. The moment one crack in the armor shows up countless agents with unending patience can start embedding themselves everywhere in timeframes way faster than human actions. You could quickly find out all the special sauce for your company has been copied who knows where.
Working with banks when the Glasswing/Mythos first came out and they were given access to it has given me direct access to their infosec departments that are panicked. They've been sitting on piles of bugs for years that were low risk enough, and they have seen in their own tests how fast they can be probed.
Worse those infosec systems that have identified the risks in their software that aren't yet fixed are nuclear waste vats just waiting to get spilled to the wide world.
Software security has just been a fun time of ignoring the exponentially growing number of bears for the last few decades so you can continue to use systems unfit for the threat landscape because they are cheap.
The problem is that most companies don't care if they get hacked so long as the hackers are just taking data and not interfering in their ability to bill customers and make money.
They face zero meaningful consequences if their data gets leaked. The money they save by not taking security and employee/customer privacy seriously will more than pay for the year of "identity protection" they'd have to pay for (assuming the hack gets found out) anyway.
They actually care about ransomware, but most of the time that's also something they can comfortably buy their way out of. We've seen a lot of companies pay off ransomware gangs rather than invest in the kinds of robust backups that would make recovery possible/less painful than rewarding the hackers.
What's needed for change is regulation with actual teeth that makes not protecting their data either meaningfully expensive or criminal resulting in executives spending time behind bars for their negligence. Without that, things are only going to get worse, especially as companies experiment with using AI and increase dependence on third parties and cloud providers who themselves become rich targets.
That probably still won't help the FBI though. Our government isn't exactly big on holding themselves accountable or even prioritizing competency right now.
Hasn't been since before Vietnam.
Experienced Ransomware gangs will set the price target as something high, but not cost more than the price of being down a few days while you rebuild, making paying them seem like the most cost-effective solution
Let's say my cryptosig gets hacked by SkyNet, or my agent goes rogue. Either way someone files a million loan applications in my name! Normally my agent uses that to buy $200/month of Funko pops, or negotiate my recent purchase of a used car.
I get the notification from my cryptosig company. I freak out, report as fraud, and wait.
They comp the $3000 advance on my loan the scammer managed to withdraw, and I get off scott free, changing nothing about my behaviour.
If cryptosigs meant I am liable for someone stealing my identity like in 2026, I wouldn't use them. I'd negotiate everything myself with document scans, or god-forbid go in person since only I can legally bind myself under my own name.
That sucks! Nobody gets a commission when I make deals with a government ID. Startups don't even allow it as cryptosigs are more secure than scanned passports.
I don't want to do that either. When I was 18, I got swindled by a human salesperson into a $1400/month 27% APR muscle car when human soldiers got signing bonuses. It was face-to-face and they were smarter.
When I let AI own the budget, it leased me a mostly depreciated BMW from another AI for $500/month. The models are mostly the same now and always settle close to the Nash equilibrium.
I was so grateful that I selected a 40% tip for the AI. I wouldn't want to make things awkward with the companion I spend 8 hours a day talking to, after all. To avoid a conflict of interest she only accepts voluntary fees.
Remove the complexity (all the way down to the hardware quirks), and security will be doable again.
Of course there is. For example, SeL4’s security and reliability proofs still hold in the world of LLMs. The problem is that most software isn’t written on that firm foundation. Instead, most software is made by people with the philosophy of “if it looks like it works, ship it”. You don’t get secure software by working like that, because security vulnerabilities aren’t visible.
We - humans - know how to write secure software. Just like we know how to make safe aeroplanes. The problem isn’t that we lack the capability to make secure computers. The problem is we don’t have a culture of security. Secure software is - somehow - niche. And as such, it’s much more expensive. And nobody wants to pay.
It's often possible. But not all systems are vulnerable to undervoltage attacks. For example, I don't think the iphone secure enclave is vulnerable to this.
And good security uses "defence in depth". Multiple layers which each individually need to be compromised to break the whole thing. To hack chrome, you need a vulnerability in the renderer or VM. Then you also need a sandbox escape, and a way to use that to attack the browser's parent process. This is much harder to do.
Then there's decapping / depotting, a world of different types of microscopy - some destructive some not, directed EM attacks, etc.
> And good security uses "defence in depth"
And automation has enabled "offense in depth"
> To hack chrome, you need a vulnerability in the renderer or VM. Then you also need a sandbox escape, and a way to use that to attack the browser's parent process.
Or you just phish the user into installing your exploit. There's always another layer. Always a potential exploit. Because ultimately the same properties of the universe which permit computation within a closed system allow for predictably observing and influencing it. The expense and hassle of doing so are widely variable, of course.
So what? Most attackers aren't nation state adversaries. They're some kid in Wyoming messing around with deepseek. We live in a world where most exploits happen because someone was running an unpatched, 8 year old copy of wordpress. Because they put their insecure mongodb instance on the open internet. Because they used admin / "12345" as the username and password. We don't need to make hacks physically impossible for a nation state adversary. Just really, really difficult and expensive to pull off.
Honestly. If people talked about physical security like they talk about computer security, you'd have people telling you that, because walls can be physically smashed through, they don't bother locking the front door to their house.
The saying is that locks only keep honest people honest. Plenty of evidence of that: https://www.youtube.com/@lockpickinglawyer
It’s not hard to get into a garage but it’s really easy to steal a lawnmower if you leave the door open all night. I wouldn’t call that thief honest but even the minor deterrent of closing the garage was enough to make you not the target.
That youtube channel is great. But it isn't evidence of anything. Except maybe for how terrible master locks are.
So what? Security systems don't need to be 100% provably secure to add value. It's a mistake to let perfect be the enemy of good.
A perfect system is either extremely limited in scope or flawed in it's assumptions.
By the way, there are countless ways to account for humans. There are entire branches of engineering devoted to this. If you don't want someone to leave the bank with a pen customers use for signing checks, you just chain it to the desk. If you don't want the installer to forget to put the pen-chain in, make a photo of the chain part of the checklist required to get paid. If you want to... etc.
The idea is that you determine an acceptable level of risk, then secure to that level. Maybe the acceptable level of risk chosen by companies is wrong. Maybe we need to increase that risk exposure via heavier fines and regulations. Maybe the cost of reducing that risk is too high already. Maybe we need to fund that. Maybe it's too confusing and we need to research better standard practices. I dunno. But this is not some unsolvable problem.
There really isn't
Ask anyone seriously involved in security - whether computer science related, or in general.
A thought experiment: Think about the most important secrets a country can have - now think how they are still discovered by competing countries, enemies, etc.
As long as there are humans in the loop there is a known weakness.
We know about many famous cases of leaks - like the USSR stealing notes from the manhatten project. But I bet there are thousands of secrets which remain secret. We just don't actually know about them, because, y'know, they're kept secret.
This is EXACTLY what I was talking about. The tech that makes the F-22 an unmitigated terror of the skies is of utmost importance, so it’s still kept secret. The barriers around that information are obnoxious, but effective. What blood type a subsection of your military has is of much less importance. That’s why that data was stolen (See: OPM hack) and our best weapons remain secret.
Decades ago, I worked in a bank in an old building. The door had a card reader for access. You boop your card and the door opened. People would hold the door open for each other all the time out of politeness, even when they didn't know each other. Security told us not to do that, but it's hard to convince people to stop being polite.
I had a laptop stolen from my desk in a place like that once. (Not a bank - but similar door-card reader system). This guy came in in the middle of the day, wearing overalls. He confidently walked through the door after someone, like he belonged there. He walked up to my desk, swiped my laptop and just strolled out.
At the bank, they've replaced the door with mechanical gates and a security guard. The gates - physically - only let one person to walk through at a time. You can't hold a gate open any more. And the security guards stop anyone who tries.
Is it 100% foolproof? No. But it's way more secure. It would have stopped that laptop thief.
There's this pernicious, defeatist attitude that if you can't make a system 100% secure, so you shouldn't try. That's misguided. Most systems can be made orders of magnitude more secure than they are today. It just takes a bit of care and work.
Look at our immune system. Incredibly complex and clever, and able to keep us alive in the face of all sorts of pathogens. It exists because of this cat and mouse game, played over millions of years.
There's people in the highlands of PNG who regularly eat each other. Of course, many are thought to have died due to prion diseases. But now these tribespeople seem to have become largely immune to prion disease. Incredible.
Your comment on PNG, seems to ignore Kuru
From an evolutionary PoV a perfect defence is overkill - with two separate defences against prion diseases in that region it's only the rare variation that causes any issue - and that rarely occurs before a new generation is birthed - ie. 'perfect' from the PoV of the selfish genes.
The resistance came about via two separate "evolutionary upgrade"(s).
It appears to me that, like BSE (aka Mad Cow disease) it really depends on exposure.
There's a twofer that skittled the Fore, a ~1900 mutation that created a new form of infectious prion proteins, and a local variation that saw less uptake in the Fore of a resistant prion protein (alongside other resistant prion protein).
So, over the highlands region, there was general resistance thanks to several evolved variations, in one specific locale (the Fore) there was insufficient resistance to the mutation that hit a peak of 200 deaths / annum for about three years(?) in the late 50s.
I can't speak to "the literature", I just had a lot of conversations with the people on the ground (Mike Alpers, etc), on again / off again, since the mid 1960s.
Who said anything about a perfect defence? And since when was that the bar?
Just, you're doing it on your own.
Paper about Kuru and mutations referenced in comment here: https://news.ycombinator.com/item?id=49719102
That's not really enough to say "We have found the gene" - it's just really good data to warrant further investigation
Also, the incubation period of the disease is up to 50 odd years, have there been follow up studies?
Computers make copying, processing, manipulating, and disseminating information easy. That is a bad thing for some kinds of information.
I work in secure systems and it’s shocking how many people believe this - the incentives from management are all about it too.
PS. Likewise, apologies, perhaps I was at fault for style: There was an underlying more serious point ...
... that, it is indeed a serious problem, that folks shouldn't be having their souls (or anything else for that matter) crushed, and that it indeed would appear to be an issue of conflicting incentives vs. management.-
We are headed for scary waters.
Only just when we started to have a resemblance of security we got agile and startups breaking things (making rubbish software to capture a few bucks faster) and now vibe coding and llm assisted hacking.
The point of my, arguably rant, is that there is nothing new under the sun.
It's not a guarantee this time will be the same - but it should temper the worry somewhat.
Previously no one was dumb enough to put that in one electronic database - it was on paper.
This is going to get orders of magnitude worse.
After the DOGE debacle, I suspect that all the previously really secure stuff, is now out there, too. In fact, I wouldn’t be surprised if some of these leaks, came from that.
FBI employee data is very bad.
This might be part of it...
> Why would anyone with the expertise to make these calls bang their head against the wall trying to educate bureaucrats about these things
But I suspect this might be most of it: good engineering is boring (to the recipient). Preemptively solving problems gets no credit.
The only solution I can come up with is some form of certification or paid code review from a third party. I know that at least for Windows prior to 7 Microsoft actually allowed some parties to come in and check the code/checksum on an air-gaped computer. We somehow moved to "trust more" in the last decade, and now we can trust nobody
LLMs have been a huge force multiplier. Here.
If that data got out (which probably happened within hours of the data being dumped to insecure storage), then it’s probably already been analyzed and used to leverage access.
Why are you so interested in defending DOGE?
Not all hacks are caused by pure negligence, laziness or stupidity, but most of them are. Even a little effort goes a long way.
My grandfather spent a couple decades as a builder, ran a construction crew. Whatever the project was, he wanted to know everyone he hired personally was going to reinforce and report to him anything they had the slightest doubt about. "Always hammer in an extra nail" was basically his motto.
What we do ain't that different. The difference is that when an apartment building collapses, it's bigger news than when a govenrment database does.
Also when a building collapses, people blame the builders. When software leaks user data, the engineers and companies face no repercussions.
- nothing is, can be, or even should be 100% secure; the optimal rate of security incidents in society is not 0 (with apologies to 'patio11)
- security is a simultaneous trade-off against costs and usability, and those two other factors are more important:
-- security is achieved primarily through raising costs for attackers to beyond profitability, and reducing impact of such attacks (due to "not in isolation from the world" below, this also mostly translates to costs)
-- if "properly secured" (in the current cybersecurity sense) product/service cannot fulfill its function anymore, then you may just as well not make it; either way, no point in paying you for security work
- security isn't done in isolation from other systems and the world at large; "if this happens we'll go straight to filing crime report with the police" is perfectly legitimate security measure (even if it works somewhat less well on the Internet); similarly, "this is secured by us having insured against it" is also a valid solution to some security problems
Those running projects with these beliefs are sputtering and producing impressive PoCs that struggle to make it into production - either through underestimating the amount of detail needed to scale, or often throwing away good practices in favor of letting LLMs handle tradeoffs that later make changes slow to a crawl.
Theres plenty of good ways to utilize LLMs to speed things up, but so many teams got so incentivized by management to move fast at any cost that they’ve thrown out “load-bearing” good practices for software. That bet hasn't been paying off the way they’d hoped. It’s now clear that they thought they’d be able to massively downsize the engineering orgs. Massive token spend is giving very little RoI and now like other companies they’re trying to rein in the biggest spenders who are often not producing value.
Eh. If only it was that simple. I mean, yes, money is always a factor, but not nearly as big of a factor as 'my convenience outweighs pretty much everything ( until it causes sufficient amount of havoc.. and even then.. )'. You can see it in just about everything. It is not just the money. It is the convenience that drives most of the unsecure behavior.
Depends on the "we". "We" have the capability to make secure computers like how "we" have the capability to make EUV lithography machines. There exists a relatively small number of people and organizations in the world who can do so. 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. All of those organizations have tried for literal decades, thumped their chests about how they have awesome security year after year, and yet have totally and utterly failed despite their best efforts.
Acquiring the capability to do so is difficult and challenging and requires years to invent if you start right this very second and know what you need to do, which these organizations emphatically do not. We need security at scale and fast. The only way forward is to scale up working solutions rather than letting the bozos who put us in this spot fail at scale with yet another promise that this time for sure they will solve the problem they have repeatedly failed at for decades.
> 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.
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.
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.
https://blog.plan99.net/why-not-capability-languages-a8e6cbd...
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.
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.
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:
https://github.com/openai/codex/pull/46500
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.
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.
You can try it now yourself in Haskell! This is my effect system, based on capabilities: https://hackage.haskell.org/package/bluefin
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.
I would like to see restricted access to only us workers for us citizens data though.
Transferring us customer data outside the country should be illegal
"So what?" you say. "Making a heavier-than-air metal tube take off and land millions of times per year without a catastrophe is also hard, and we no longer expect most or even many of those tubes to blow up or fall down."
Mother nature is not spending $$$ using AI and HI adversarially trying to find the exact combination of atoms that will cause your device to fail.
Modern CPUs support IOMMU. If you set that up, your NIC can only DMA to virtual addresses, managed by the operating system.
> It doesn't help with timing attacks. It doesn't cover your network stack
It does help with all this stuff, because your network stack and whatever else can be split off into isolated processes which talk over capabilities. Compromises in those processes are of course terrible. But they don't automatically allow kernel level takeover of the whole machine like on windows / linux.
> "The output from the SM_FORCES application code as required by a MSOP Project Software Interface Specification (SIS) was to be in metric units of Newtonseconds (N-s)"
(MSOP = Mars Surveyor Operations Program). One of the recommendations was
> "Conduct software audit for specification compliance on all data transferred between JPL and Lockheed Martin Astronautics"
So yes, NASA should have checked the provided software more thoroughly, but also Lockheed should have actually followed the spec they were given. I doubt the SIS is available online to check any harder
Both parties fucked up.
Lockheed's job is to follow the customer's specifications.
NASA's job is to check to make sure what they paid for is what they received.
I do this every single day as a quality inspector here. I don't know why a bunch of highly-degreed engineers can't do a simple job that a person with oonly a GED does without fail.
Tell me you don't run AS9100D quality inspections without saying so directly.
Besides it looks like the first AS9100 Standard was released after the incident even happened - perhaps even as a result of this.
So it's totally irrelevant that you both audit software in the space and know the Standard, no pun intended
Again, tell me you don't actually handle quality without directly saying so.
So physical security is just as important. I really like how ARINC serial bus on planes work. One can have a reader that is physically incapable of sending anything to the writer. This allows to connect entertainment systems to flight data sensors safely.
In Airbus this system is replaced with Ethernet switches that in software ensures separation of traffic. The software was proven mathematically. But I am skeptical that it is absolutely bulletproof as a client under malicious control can influence Ethernet signaling and may exploit hardware bugs.
Nobody said sel4 was a panacea.
My claim is that doing this kind of computer security is possible. It's just expensive and inconvenient. We know how to make computers a lot more secure than they are today. The limiting factor isn't humanity's knowledge. The limit is that barely anyone wants to pay the bill.
Do you even have any experience with how most companies work? SMEs barely have the cashflow to cover their daily expenses, let alone suddenly pay thousands for regular professional security audits and overhauls of their code. This is why security is an afterthought.
Security is always a cost center and rarely a profit center. That's the only thing that needs to be said.
If builders can't build houses to code, and the buildings fall down, they shouldn't be allowed to stay in business.
If civil engineers build bridges that fail. Or doctors hurt patients. Or police officers shoot innocent people, they shouldn't keep their jobs.
Software engineers are no different. If you collect my user data and it's at high risk of leaking on the dark web, either clean up your act or close shop.
That means designing the ecosystem pressures is crucial: things more meaningful than just pure capitalist private-profit logic must by enforced by thoughtful regulation or otherwise the ecosystem converges for private-profit of a small sliver of individuals (billionaires) to the detriment of all other ecosystem members (99% of the world population).
This holds for anything broader than pure private gain, may it be security, social fairness or ecological topics. Sole monetary-value optimization for private gain must be properly constrained or else it results in pure predatory capitalism that implodes society from within, may it be through leaky security, poisoned environments or social unrest.
You mean something is theoretically possible, but in practice only works at small scale and is otherwise effectively impossible. You only have so many resources for all those big topics.
And after you spent all the world's resources on the "perfect", formally bug-free software, you get hacked via social engineering or malicious insider.
But your evidence does not support that claim. SeL4 has proven that it is possible to design a secure microkernel and prove its security guarantees. It does not prove that you can build entire systems (filesystem+database+web server+browser) on top of that kernel while maintaining the same security guarantees.
I'm all for improving the state of computer security, and I'd love for capability systems like SeL4 to become more prevalent. But it's only a microkernel, and it's by no means certain that the PeopleSoft vulnerability exploited here required a kernel-level compromise.
Wasm does this. Erlang does this. SeL4 does this. Chrome is built this way. The windows driver model is moving this way. And so on. You want a solid core to build around - which is what SeL4 and beam try to be. Then it’s up to us to use those primitives and build good software. Combine that with a memory safe language (rust, go, c#, etc) to protect against buffer overruns and use after frees. And a picture starts to form of how you can build software that is a lot more secure by default.
I don’t think perfect security is worth the cost for many companies. But so many security leaks happen because of amateur hour somewhere. Bugs happen - I get that. But a single bug in a C++ program shouldn’t immediately lead to RCE with system level privileges. This stuff isn’t rocket science.
Oftentimes the weakest link is the human operator who has direct access to those systems, not the computer system itself. Good old social engineering, in other words.
Even though one could use LLMs for social engineering, come to think of it, like re-enacting the movie "Her" involving a modern AI as Scarlett Johansson and an engineer working for the water utility as the romantic target.
If that is the case, the computer security team have done their jobs.
I wish that were true more often.
> Of course there is. (...continues to talk about software security)
A bit over-optimistic when looking at hardware vulneraribilties like Spectre/Meltdown.
Secure software isn't worth much when it runs on vulnerable hardware (at least Spectre/Meltdown could be worked around in software though, but at a cost.
You know that's their actual job right? That and fixing the problem. Which they did in both software and hardware.
Looks to me like the security researchers have been doing their jobs.
Its not expensive because its niche, its expensive because its hard. Its a lot easier to learn a bit of html and javascript and knock up some web projects then it is to become proficient at all the things necessary to be good at security. Generally it also takes consulting with maths experts who have spent their life studying cryptography and as such command a decent wage.
It doesn't take a maths degree to look out for SQL injection attacks or to audit software & write up a risk assessment.
There wasn't.
Computer security is expensive but that expense has nothing to do with cryptography.
I'd counter and suggest it is expensive because almost nobody gives a damn about the first 3 layers in the OSI model, and have pushed most security responsibility up to layers 4-7. That's roughly half of your attack surface still exposed.
And one screw up, and it’s out.
But most important of all, the highest level - human operators - are not provable secure anyway. Any castle gate can be opened from inside - so why have the gate anyway? Security by absence is absolute
Followed up with a lot of “we just make the tool, we can’t be held responsible for how it’s used”.
https://www.yahoo.com/news/politics/articles/flock-ceo-asks-...
A linux box, layered in encryption and not plugged into any network = damb secure.
A network-connected linux box with a hardened OS, firewalled, acting only as a file server, given regular updates and 24/7 monitoring = less likely to be "hacked" than struck by lightning.
A hard drive with its power supply physically switched off = 100% secure from external attack.
Not a joke. The keys for editing the world's most important files, the root zone, are kept on no-power drives in air-gapped safes. They have yet to be hacked.
Most control still works this way. See the postmortem on the Iberia black start. Renewables that were trying to do frequency following drifted out of sync and injected misaligned power into the grid. They couldn't even figure out where it was coming from their telemetry is so bad. Then they were asking the gas plants to spin up to add inertia but it was too late as the boilers were cold. IT and other smart grid ideas were conspicuously absent.
Of course they do. Not everyone has the level of technical expertise the average HN user does. Turning around to them and saying “duh of course all your personal data leaked” doesn’t feel like a helpful response. Especially when they don’t even have control over where their data lives anyway.
Nobody I know in security hardening or vulnerability research has ever believed that anything is perfectly secure. It's not black and white. There are degrees to this.
I find this fatalistic thinking that every database should be assumed compromised to be subtly harmful. Everyone I know who thought that way waltzed right into lax security practices. "Good enough, what's the point, if anyone wants it bad enough they're going to get it anyway"
For every engineer that takes security seriously, there are 99 engineers that don’t. It’s an uphill battle.
Source: 25 years of experience.
There's a reason that many military and intelligence organizations worldwide physically cut / remove wifi and bluetooth chips from boards. The same is done when audio is identifiable, and specific hardware (only) greenlit.
I've lost hours of my life to calls explaining exactly this, only to have people ignore it, only to further have folks come back, tail between their legs. The worst part is learning this in industry, as I did. There's a reason for in-industry advisors. I wish that I had learned this the easy way.
The problem is, most water, sewage and even many electrical infrastructure isn't manned any more. You need some form of remote surveillance and control, and practically, you will need to go with some sort of VPN based network.
Depends how the house was build. Here in europe there are plenty of old houses build in areas that experienced periodic flooding - there the advice is simply, do not store anything critical in the basement.
If you have ${anything}, assume it is semi-public, meaning if someone was interested enough in accessing it, they could do it. "Fort Knox" isn't the right analogy for physical security; the primary question isn't whether something can be breach, but how much would it cost the attacker to do it.
A system where expected costs to attackers >> expected profit they could reasonably make from succeeding, is considered secure in typical case (exception: special cases where attackers may be driven by non-material reasons - think terrorism, politics).
Computer security is largely still stuck in "Fort Knox" thinking.
> For example, do not hook your goddamn water or traffic or electricity infrastructure up to the goddamn Internet, and then, do fire the guy who suggested it.
That ship has sailed. "Modern problems require modern solutions", that infrastructure will be in some way accessible over network is a necessity at this point, the question should be, how to keep it difficult for normal attackers to mess with it, without preventing the system from fulfilling its intended function.
> The correct analogy for computer security is not locks and keys and doors and gates. It is a house in a floodplain. Your house will not survive the flood of it hits you. Do not store anything critical or irreplaceable in that house.
The correct analogy for computer security is a house. Scale security proportionally to actual importance of what's inside, and accept that nonzero amount of houses will be broken into; that's just insurance writeoff. Leave the 20-meter walls with towers and armed guards and helicopter gunships on fast-dial for the critical junctions, while keeping in mind that this is not perfect either - it won't stop an open nation state attack, at best maybe slow it down.
For critical infrastructure, I'd honestly focus on redundancy, resiliency, limiting blast radius and procedures to recover quickly, over trying to turn every physical or virtual substation into unpenetrable fortress.
(Another thing physical security gets right, that cyber side seems to ignore: security does not and cannot exist in isolation; criminal justice system and law enforcement are part of it, and at extreme end, threat of military intervention against a state that aids and abets the perpetrators. The possibility of sending "men with guns" after perpetrators is core part of securing a system or space, it's literally what they are for and why we fund it with taxes.)
There is such thing but almost never a priority. In the corp I work leadership talks a lot about security but when comes to the incentives the road-map takes priority over the security. If you deliver fast you'll be promoted, if you're a paying attention to the security no-one will appreciate it and the manager will hate you for delaying delivery. Many managers I interact with see new features as the main value development teams should provide and security, reliability and other QoS as a waste to be minimised.
Another issue is that even if security will be a priority and managers will be on board (good lock changing the culture tough) we probably cannot build secure systems while keeping the insane level of complexity we have nowadays. Switching to simpler but secure system will require sacrifices in features/convenience.
That doesn't mean that all of your neighbors know your medical history, but you have to assume that someone who wants to know those details about you will know them.
I have lost faith in people protecting any significant database from hackers.
Most security professionals I've met in my career border on being non-technical, there are of course security researchers and a whole arcane and academic field that exists well beneath the surface but it is so far removed from the every-day.
I am more concerned about my cloud data being published in a leak.
But then on the other hand, if I use mainstream cloud services, a broad leak with no specific interest in my data would need to be exabytes in size and would take years to transfer even with a 100 Gbps connection.
Ask the Iranians how impenetrable even physical isolation actually is - their centrifuges were still destroyed even though they were air gapped (the infamous Stuxnet). Ultimately all computerized systems are vulnerable to sufficiently determined cyber-adversaries.
You also need to make various cost-benefit analysis decisions for all of these things. Does the extra security you gain by keeping your system disconnected from the Internet actually increase all-around availability and resilience?
In particular, integrating highly variable power sources like solar and wind into the grid requires much more complex synchronization between producers, storage, and consumers in order to function properly. Trying to build a renewable grid without Internet access is doomed to extremely inefficient, if possible at all. Building an alternate network would be extremely expensive and ultimately useless (since every house in the country needs to connect to it, it would be just as vulnerable as the actual Internet anyway). So, ultimately you must connect your power grid to the Internet to actually provide service, despite the security risks.
Perhaps the situation with the water supply or traffic is different, so maybe this is not as applicable.
There were only two VM escapes from Qubes OS in the last 20 years [0]. How is this not sufficiently secure?
https://forum.qubes-os.org/t/qsb-116-multiple-xen-issues-xsa...
CHC is the largest claims clearinghouse in the US; about 100m people's insurance claims go through there each year.
The hackers asked for a ransom ($35m iirc) to delete the data, which United Healthcare (who owns them, because of course they do) paid. But it seems that the collective negotiating on behalf of the actual hackers rug pulled, so the actual hackers didn't get paid.
This is more than simply medical records. It includes who is active duty military and their family. If you can map where soldiers are, you know roughly the size of different military bases. If you know which types of capabilities are operated out of which bases, you can get a pretty good look of how the US is allocating personnel.
It was crazy working on recovery from this at the time. It should have been front page news, but wasn't.
I guess your parking history around town could be valuable if someone is targeting you.
The card number?
When your lifetime of credit card transactions leaks, that could be financially painful, embarrassing, etc. (can be discriminated against, including with pricing)
I do dislike creating a log of where I park on some random company’s server. Nice that ALPRs/govt.-funded corp spycams/Ring/etc. make sure the quarter method is minimally marginally effective at protecting privacy.
I had to fight a bank for months over a clearly fraudulent charge. Sometimes it's easy; other times it isn't.
Can’t speak to fraudulent bank charges, by the way, only on the credit card side.
This is also partially that people don't put critical bills on their credit card typically. And even if your credit card does get maxed out, you typically would have a second credit card handy. But those credit card payments have to come out of your bank account and so you're risking that you intend to pay your credit card you said Set whatever it is to send the money in but there's no money in your account And so it doesn't get paid and now you have late fees on other accounts
If your debit card is going to a different bank than what you normally pay all your bills out of, this is not a worry. That is not how most people I know handle their banking though, which is why it is a real problem to worry about.
This is probably atypical, as the average people I know put their critical bills on their main credit card that they use everywhere:
I put my autopay bills on a credit card that sits in my safe. The only reason it would see a fraudulent charge is if one of the few companies that has the card information, is hacked. And that actually happened once.
Perhaps not everyone has a good credit card and/or bank though, idk.
One, how much money is in your pocket so you can eat?
ok, you'll use your second ca.... oh, it has to be cancelled now too.
Ok, lets wait a few days for another card, and lets go use it the first time, what hacked already, I guess I need to wait a few more days.
>As long as you're not using a debit card, this is not a big deal.
So screw 60% of all transactions done on a card? This doesn't seem workable.
I have a text alert setup for transactions, so I presume I’d be able to successfully challenge any fraudulent ones pretty quickly.
It's a good practice to keep an emergency debit card at home. And/or a gift card with a couple hundred bucks on it. That's for digital expenses.
And you should also have a bit of emergency cash.
The chance is incredibly small that your second card just happens to get hacked at the same time as your first card.
I have 6 (I think) credit cards, and mainly use 3 of them.
Consumers aren't gonna notice the difference if the site gets hacked and that JS is swapped out for a malicious set.
"I'm only talking about long-term storage" is itself a goalpost move!
For example, you have to trust the QR code takes you to the real app: https://www.bbc.com/news/articles/cwyjqg578e1o
Not much, Revolut just got tricked by hackers into giving out customer information: https://news.ycombinator.com/item?id=49682087
I'm not just talking about bids. The idea presets itself prolifically. We all work in tech, I'm sure you see it on a daily basis. Rush Rush, no time to think, just do it. 6mo later, "there's so much shit! How could we have ever prevented this?" Rinse, lather, repeat
If somebody wants data about me, they can write the query, I'll approve it, and it can hit a server designated by me and run by somebody I know personally.
It's not just a privacy/security concern. People who get too close to large piles of sensitive data tend to start behaving poorly in other ways too--they might be compelled to misrepresent it. Apparently the forces of corruption are too great. Maybe the way to avoid exposing each other to such hazards is to just maintain smaller piles of data, closer to the people that the data is about.
If the users know their admin, then each server has no more than few dozen other users' worth of data on it. The juice just isn't worth the squeeze to target them one at a time. Ain't nobody has the resources for that kind of attack.
Also, it's a lot harder to phish somebody who is on a first name basis with 100% of their users. It's not enough to merely have a plausible backstory, you have to impersonate one of their friends. That's incredibly difficult.
The only thing left is to hack through whatever protocol indexes these servers and multiplexes queries across them, but now you're presenting a much smaller and easier to defend attack surface, one which can be defended in aggregate (e.g. supply chain scrutiny) rather than singly.
I think privacy will remain, perhaps even improve, because people are much less inclined to snoop when it cannot be done covertly. No secrecy means no covert activity.
Information is everywhere and with the increasing ability to analyse it, not only does it enable access to explicit information, but the ability to infer from increasing volumes of data that will make it hard to hide anything.
Spectre reads protected memory by tiny vriarions in timing. You can now measure the pulse of people from film. You can recover audio from a room by analysing frames of a video recording of a chip packet taken with mobile phone camera. Even as far back as ww2 intelligence on the success of attacks could be measured by the price of items impacted by different types of infrastructure damage.
This kind of data residue is everywhere, collecting only what is publicly available can probably tell you more than you could hope to know about anything that happens. The only thing preventing it is the ability to consider it all together. Those walls are swiftly crumbling.
It’s entirely possible to keep large databases secure. It takes competence and commitment though, something federal police don’t have for IT.
[0] Everyone gets hacked, but not everyone has all of their most secure data exfiltrated.