Profile cover photo
Profile photo
Clear Linux Project for Intel Architecture
Cloud Linux
Cloud Linux


Post has shared content
Intel's Clear Linux operating system is now available on Microsoft's Azure public cloud platform!
Add a comment...

Post has shared content
Clear Linux receives the latest GNU/Linux technologies, including Mesa 3D Graphics Library 12.0.0, Linux kernel 4.6.4, Rust 1.10.0, and more!
Add a comment...

Post has shared content
What was the most amazeballs moment in open source for you, in 2015?

For me, it was earlier on in the year, when my views were ever so slightly shifted on virtualisation, and how we build Linux based operating systems.

Now, as anyone knows, I have my own particular opinions on how one would approach the Linux side of things.

With that said, +Clear Linux Project for Intel Architecture was a real eye-opener for me. And I really mean that (cue the shill accusations)

The project takes an incredibly direct approach at all problems, and it's really rounded me off as a developer. "This is stupid, let's fix it" [1], and things indeed do get fixed.

We now have Clear Containers booting in a ridiculously short amount of time (hundreds of ms) using full virtualisation, giving true isolation from the host kernel and operating system (vs simple namespaces).

Even in a bare bones setup, Clear Linux is still wicked fast.
We completely shifted how stateless was approached and implemented on Linux, and ship the only true stateless Cloud Linux (Sorry, systemd factory files doesn't count :P)

Then look at how Clear Linux is actually built. We heavily automated an enormous amount of daily work, such as adding and maintaining packages, initial auditing of the image. We've also got Continuous Security Integration, of which I'm happy to say my cve-check-tool is a part [2]

I'd be lying if I said I didn't find Clear Linux's work applicable in other areas, and I've openly stated that I've adopted some practices and features into my own distribution.

In short, 2015 was awesome, and I'm so happy that I could be a part of that, working with some truly amazing people!

[1] Not an actual quote, just my interpretation.
[2] cve-check-tool re-enters feature-development Q1'16
Add a comment...

Post has shared content

Post has shared content
Another awesome part of the +Clear Linux Project for Intel Architecture developer experience has just been uploaded to GitHub.

"autospec is a tool to assist in the automated creation and maintenance of RPM packaging. It will continuously run updated builds based on new information discovered from build failures, until it has a complete and valid .spec file. The tool makes use of mock to achieve this."

It's an absolute joy to work with on a daily basis, and drastically simplifies lifetime maintenance of a Linux distribution, along with vastly reducing the initial packaging time/cost.

Go take a peek! :)
Add a comment...

Post has shared content
Clear Containers for Docker* Engine are now public. Previously Clear Linux* Project for Intel® Architecture demonstrated lightening fast Virtual Machines. And from today, once can run existing Docker* containers in this secured and fast execution environment. Clear Containers for all !!!
Add a comment...

Post has shared content
Deprecating Old Crypto in a Linux Distro: A tale of something that looked obvious but .. there's a lesson in it somewhere.

While working on my Linux distro project at work, one of the things I recently wanted to do is phase out old crypto.

Yes we all read Bruce Schneider's text and how important it is, but nothing drives it home like reading The Guardian articles followed
by OpenSSL downgrade attacks in the last year or two.

Now, nothing should be defaulting to some of the antique crypto, but the only way to know 100% sure  that the algorithms in question aren't being used, is to just not compile them into the various crypto libraries of your distro.

So.. step 1 was to look at the algorithm list of openssl:

arjan@clr:~$ openssl ciphers


A few things stand out immediately.

RC4. This like seriously predates MD5, and MD5 is already suspect.

DES. Yes really. DES. in 1995 I worked at a company as an intern that made DES chips that you could use to brute force DES. In 1995, when Twin Peaks was on TV  and you measured transistor sizes of a chip in micrometers not nanometers.

MD5. The general consensus seems to be that for crypto, you shouldn't use MD5 anymore. I'm not talking about SHA1, where one can argue that existing uses are still ok, but MD5.

I decided to draw my first line there, stick to the consensus and all that.

The good news is that OpenSSL is very configurable, and it's pretty easy to say

no-rc4 no-des no-md5

on the configure line (and for good measure, I added no-ssl2 and no-ssl3).

At this point, I thought I was on a roll, removing old crypto is easy, lets finish this 15 minute project before the project meeting starts.

So now on to the bad news. And sadly, there is plenty to be had.

openssl does not even compile with the no-md5 option:

make[1]: Entering directory '/builddir/build/BUILD/openssl-1.0.2a/ssl'
In file included from s3_srvr.c:171:0:
../include/openssl/md5.h:70:4: error: #error MD5 is disabled.
 #  error MD5 is disabled.
In file included from s3_clnt.c:158:0:
../include/openssl/md5.h:70:4: error: #error MD5 is disabled.
 #  error MD5 is disabled.

Ok, so MD5 is technically not insane broken for small packets, and
it's just consensus not so much hard earned proof, so maybe deprecating md5 is a project for another day.

openssl does not even compile with the no-des option:

make[2]: Entering directory '/builddir/build/BUILD/openssl-1.0.2a/apps'
../ undefined reference to `EVP_des_ede3_wrap'

or when you fix that, it does not pass its test suite (I'll spare you the details). 

Now here I had to draw a line. 20 years ago DES was not secure.. never mind today. I wouldn't  be surprised if someone will chime in and say that their smartwatch can brute force DES in realtime now.
So.. fixing it is.

I suppose the good news is that no-rc4 went just fine.

The success story then, with the list of crypto from openssl after no-rc4 and no-des:

$ openssl ciphers

no DES, no RC4.

But, as it was a Monday, the misery only started there (Dave Jones should have taught me that misery is like lawyers, it always comes in pairs).

I threw the no-rc4/no-des package into our build system, and in no time the world came apart on me. Half the distro broke!
Well not half, but several very important pieces.

It turns out that components like curl, libcurl (so anything speaking http), wget, openssh, mariadb, ...

all hard-code DES usage. Now, I'll give curl credit, with creative use of configure options, you can make it not compile DES in, but you can't then make it pass its testsuite.

There must be a lesson in here somewhere.

One, our team will be fixing these projects to not require DES (or RC4), and we'll send those patches to the upstream projects of course.

But more, and this is a call to action: If you're working on an open source project that uses crypto, please please don't opencode crypto algorithm usage.
The algorithm may be outdated at any time and might have to go away in a hurry. 
And if you have to use a very specific algorithm anyway (for compatibility or otherwise), at least be kind and make a
configure option for each algorithm in your project, so that when things go bad (be it in 5 or 20 years), its very feasible to disable the algorithm entirely. 
Add a comment...

Post has shared content
Boiling frog, or when did we loose it with /etc ?
$ sudo find /etc -type f | wc -l 2794 Stateless When was the last time you looked at /etc and thought - "I honestly know what every single file in here is". Or for example had a thought "Each file in here is configuration changes that I made". Or for exampl...
Add a comment...

Post has shared content
Tools are important.

Whilst its true that distributions are made up of great software, it is equally as true that they are built with powerful tools. Nothing is more important to a distribution developer than a healthy arsenal of tools at their disposal.

A point where this becomes particularly prominent is security. To address parts of this problem, we developed cve-check-tool for +Clear Linux Project for Intel Architecture. This tool, in a nut-shell, analyses the source repository of a distribution and compares with the National Vulnerability Datababase to determine whether the software is affected by any non-embargoed CVEs.

This database is updated every 3-4 hours, detailing CVEs from 2002 up to the current minute. We cross-reference the database, determine applicability, and whether we've already addressed the issue or not by patching, etc. Security has many facets, and this only represents a small element of the entire process, but it does indeed strengthen the process. 

We opted to build the tool in such a way that it could be adapted to multiple distributions, so that all could benefit from it if they so choose. In the screenshot below you can see data taken from +Evolve OS's repository, indicating applicable and addressed CVEs. Note in this example mutt is not actually present in the binary repository, but is used for the purposes of demonstration.

The tool is fairly new, and if you're interested in adapting it to your workflow, take a peek at the git repository on GitHub:
Add a comment...

Post has shared content
One of the things we've been working towards within +Clear Linux Project for Intel Architecture  is having a stateless operating system. In essence, there should be no requirement for configuration files to litter /etc/ for a functional system.

Within our implementation, we've ensured that it is still possible to override the sane defaults provided with the software with a site configuration, in which case configuration files that are in /etc/ will then be respected.

A major upside to this is the ability to reset the system at will. To go back to the "factory state" - I can simply remove all of my custom files from /etc/ and reboot, and my installation goes back to exactly how it was when I started out.

We're also upstreaming and documenting this implementation, which will make life a lot easier for other projects who are also currently seeking to convert their systems into stateless ones.
Add a comment...
Wait while more posts are being loaded