CLIP OS – France’s cybersecurity agency’s open source, secured operating system
ssi.gouv.fr
ssi.gouv.fr
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.
> 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.
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 whole point is that electronic devices that can't be accounted for has to be kept back until they can be, or destroyed.
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 ;)
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)
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.
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...
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.
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]
It would be better (and create more interesting discussion) to pretend that one is reading a title that says “security enhanced” operating system, and evaluate the merits of incremental improvements offered, and not debate whether or not anything can be truly secure.
The original French text (https://clip-os.org/fr/) says "système d’exploitation durci" (hardened operating system) and this has been translated as "secure" in the English version of that same page.
It seems as if it is just the base system for now (and a bit complex), but I think this kind of architecture is great for “IoT” use-cases when the source of the sensor data should be protected from the containers who are processing the data (i.e. in sealed environments). Can't wait to try this.
Is firmware a "hardware-based mechanism" with comparable isolation claims to a TPM, MMU or IOMMU?
See the talk "Firmware is the new Software", on attack/defense of UEFI firmware vs auditable open-source firmware like LinuxBoot, https://www.platformsecuritysummit.com/2018/speaker/hudson/
edit Oh, I hadn't seen that document: https://docs.clip-os.org/clipos/architecture.html
So, container-based isolation between applications & users. I don't see anything about authorizations, though.
Source: French girlfriend, French friends and having been there a lot.
What’s more is there’s a funny reversal occurring where people insert English phrases to be hip, eg in the middle of a French sentence, you hear a “yes” or a “let’s go” or a “in z pocket” (I never understood that last one)
Much of what happened at the UN in its early decades was in French first, then English and the rest. I could see this happening at all levels within France, since it has such pride in its language. Unless that's an outdated notion, too.
1. The main mechanism for environment isolation is different:
a) CLIP OS leverages Linux kernel primitives to create containers with the help of additional features brought by Vserver, Linux kernel hardening (grsecurity for version 4) and a tailored Linux Security Module (LSM). This approach allows a fine-grained control on the data exchanges between isolated environments (e.g., handling a notion of files, processes and sockets) and permissions (e.g., restriction to ring 3 features for malicious code, limitation on the allowed system calls).
b) Qubes OS leverages hardware based virtualization with an hypervisor (Xen), and a main virtual machine (dom0) which is a GNU/Linux system with services handling data exchange between virtual machines.
2. Administrators have different roles and power:
a) Administrators on a CLIP OS system are not able to compromise system integrity nor access user data. They can only access a restricted set of configuration options.
b) On Qubes OS systems, the main user of each virtual machine is also the administrator of its own environment. The system administrator of the main domain (dom0) can change all the configuration options and may access all user data without any restriction.
Way to disappoint me. I was expecting some cool pure microkernel goodness, perhaps based on seL4.
Linux can't be made secure for a very simple reason: The kernel is huge, and all of it runs in supervisor mode.
Maybe making a full fledged sel4 OS would take years ... I don't know.
Pragmatism pulls in the non-security direction. When security people see "Linux-based", they already know the thing is situated at some particular point on the scale, or worse. Linux has big TCB surface, so it's intrinsically hard to secure.
Is an understatement.
It can't be made secure without rewriting the kernel using a proper system architecture, and then it isn't Linux anymore.
It won't ever be there without a rewrite with a microkernel architecture. Which realistically won't happen.
So, it won't ever be.
(The people who insist hypervisors are microkernels are ignorant of both technology and history.)
ESX and Xen are more like monolithic kernels. The problem is that in practice they've become mini-kernels with their own driver systems and increasingly large code surfaces, recapitulating the mistake of monolithic kernels.
seL4 actually can act as a hypervisor, and their build framework comes with support for building Linux guests into the bootable system image. I don't know if there are proofs of security wrt to the hypervisor, nor what the worth would be considering how complex the CPUs are these days, but I'd have much more trust in seL4 as a hypervisor and driver framework than in something using FreeBSD or Linux as the critical guarantor of system security.
If you're stuck with commodity x86 or ARM hardware and really want a strong architecture, seL4 is the best option unless you want to build from scratch. Apple uses another L4 derivative as the OS for its security chips; an in-house derivative that predates the seL4 project.[1][2]
[1] https://microkerneldude.wordpress.com/2016/04/14/so-the-fbi-...
[2] https://www.blackhat.com/docs/us-16/materials/us-16-Mandt-De...
Hypervisors don't imply more secure.
>(The people who insist hypervisors are microkernels are ignorant of both technology and history.)
Truth. However, hypervisors implemented without microkernels won't be secure.
Look at Xen and its large TCB for an example of doing it wrong.
Look at seL4's VMM for an example of how it is done properly.
That said, I am also disappointed that everyone who cobbles together a Linux distro these days insists on referring to it as a new OS, because I remember the days when people actually announced new OSs like Syllable, AROS, SkyOS, and Haiku.
Lately I've seen the term "Operating Environment" emerging as a way to further delineate an actual "new OS" from something that just sits on top of an existing kernel but is more different than just a new Linux distribution.
A Linux distro isn't an OS, because it's a distro.
Rather raises the question of what, if anything, is an OS.