> Just don't. Please don't. You can have the most sane architecture, but there's a whole pile of s..tack underneath. You can't even trust a modern CPU.
Wasn't it determined in 1974 that you can't successfully do that using conventionally developed software, even without the bloated modern "stack?"
Multics Security Evaluation: Vulnerability Analysis:
https://csrc.nist.gov/csrc/media/publications/conference-pap...
Thirty Years Later: Lessons from the Multics Security Evaluation:
The way I see it, sensitive information should be offline. But you often need to access it in an automated manner. So set up a secure interface. Secure means that the protocol is minimalistic and you are monitoring unusual access patterns. E.g. serial interface with the sensitive data computer, where you only ask for X and it provides you X. Almost never you need to fetch all data at once. So you can set up some hourly limits or whatever. You can use microcontroller to validate data transmission. You can set up a hardware button if necessary. The beauty of it, is that the sensitive box could be running windows 3.11. The attack surface as minimal as it can be.
When you have it on a computer that's connected to the Internet, in my eyes you already lost the game. I'm quite convinced it looks the same in the eyes of some 3 letter agencies, and it sure gets an average script kiddie excited.
Anytime someone suggests that they have a "secure" piece of software without providing caveats relating to the inherent insecurity of every modern CPU and firmware stack based on closed-source proprietary blobs that the software will undoubtedly be running on it alerts to anyone with any meaningful understanding of the complexity of security that they are at best omitting crucially important information and at worst incompetent.
Sure, the size and complexity of the Linux Kernel is a problem, but the crumbling foundation needs to be addressed before problems with the first floor.
I think they are trying to prevent human error by compartmentalizing the system so they can work with sensitive data and avoid commingling it with public data.
Anything that attempts to mitigate that in one way or another is to be welcomed.
From browsing the docs[0], CLIP OS looks like an interesting project. However, I do question how much of it is.
One of the more interesting approaches using containerization in recent years is sandstorm.[0] It's unfortunate it wasn't a commercial success, because a lot of the ideas in there would go a long way to mitigating the majority of breaches that can occur at the userspace level.
In sandstorm, web apps are containerised in a really minimal environment. Each app only has access to files it operates on. There is no procfs or sysfs. All communication with the outside world takes place through a unix socket that is opened by the supervisor.[2]
I posted a while ago that there was a customer (tied to the military) that forbid ANY outside electronics of any type to enter their facility (main gate where you parked was ok, but you still turned everything over) without approval, and no electronics could ever leave. They went so far as to keep and presumably destroy anything that entered... bring a laptop, it's gone, be stupid and carry a phone, gone (nobody actually did the phone thing as you were warned plenty of times).
Granted they paid a ton for it (for a laptop many times sometimes (other times they gave you one)) and it is mostly a policy only the military can be strict about.
But having said that this was before smartphones and etc, and honestly now a days that seems like what was an extreme policy, is actually a good policy for many such places. We're already at the point where we know we can't be sure about declaring any equipment "clean".
I was a little shocked to hear the White House was talking about banning smart phones in some places.... like how the hell haven't they done that already? A mic and camera on each person that wanders all over the world connecting to random cell towers and wi-fi and OMG, what a great attack vector!
The most funny was a repair guy from IBM or Cray in the 80ies or 90ies was tasked to repair a broken storage array in a super calculator doing some sensitive computation.
He expected one of the disks to be dead (at the time those were quite expensive) and brought a new one.
He plugged it and it was not that, the array was still KO. In the end it was a broken (and much cheaper) controller card. So he fixed it, and starting to going home. But the guards didn't let him go back with the expensive spare drive and the brand new drive had to be destroyed.
There was some conflicts after that on whether or not the destroyed drive was part of the maintenance contract and who should pay for it (the government agency or the company doing the support and maintenance).
Generally though there's not much to be confused about in my experience, it is typically in the contract. When I went onsite if they demanded the equipment for security reasons I just handed it over... you'd be surprised how often security guy or IT security guy suddenly doesn't like being responsible for some cards or such and lets you go ;)
The whole point is that electronic devices that can't be accounted for has to be kept back until they can be, or destroyed.
Building your security solution in an ivory tower and then pushing on people will result in an utter failure - see PGP or password post-it notes on monitors.
(Administration in French would be the government in English - as in government shutdown, while government means administration in English - as in the Trump administration)
They have several attack scenarii, for which they need to provide countermeasures.
They are listed here: https://docs.clip-os.org/clipos/security.html#threat-scenari...
Though I've always said it should be a one-way / connectionless transfer of the OS data to the sensitive computer, with the human mind as the bridge to a connected machine. Thing is, we actually do this some places, but air gaps don't work. People say they do but they don't. Someone fucks up at some point.
ASIC + no interfaces might work. But sensors are essentially interfaces, though they're much harder to exploit, and if you have no sensors and no interfaces then the device isn't going to be able to do anything useful.
Edit: Interesting that these guys focus on fiber. It's also possible just by using UDP and cutting the return lines on an ethernet cable.
So this might check enough security boxes to allow public data and the data classification tier immediately above that on the same box. That might be as innocuous as HR data or something that could be released to the public after redacting some personal information.
Granted, my charitable speculation would require some inflexible or impractical data handling rules but I think a government bureaucracy could more than manage that.
Just don't. Please don't. You can have the most sane architecture, but there's a whole pile of s..tack underneath. You can't even trust a modern CPU.