Foreword: This article has originally been written for the Interdisciplinary Journal of the Environment Tvergastein, and has been published in its 9th edition. Thanks to the journal’s commitee for allowing me to re-post it on my blog (great for search engines), but definitely bad for the styling… Finally, I would like to thank Outi Pitkänen for motivating me to write this article, reviewing it countless times and pushing me to make it as accessible as possible!

Our society relies more and more on smart devices to ease communication and to be more efficient. Smart devices are transforming both industries and personal lives. Smart and self-organising wide-area sensor networks are now used to increase the efficiency of farms, cities, supply chains or power grids. Because they are always connected to the Internet, they can constantly and accurately monitor assets and help deliver what is required precisely when and where it is needed. Also the general public has seen the transition to smart devices, cell phones being switched to smartphones, TVs to smart-TVs and cars to semi-autonomous cars.

As I said in the previous article, I have dedicated a lot of my spare time on learning Finnish. It is by far the most complex and weird language I have ever encountered. To give you an example, I will explain what are the rules that I need to have in mind to write one word: cheaper.

Hey everyone, long time no sign of life!

I have been quite busy at Intel, helping here and there on mesa, the kernel or the X-server. I have however recently been focusing on the testing side of the Graphics Stack and got my testing project on Freedesktop (EzBench) which I also presented at XDC2015(LWN recap), FOSDEM 2016 and XDC2016 (which I organized in Helsinki with Tuomo Ryynänen from Haaga-Helia Pasila).

I’ve needed a tool to draw timelines and dependencies between tasks lately, to help me schedule the studies I’m running and writing activities (been told I should publish more, heh!). I ended up using the desktop app ’GNOME Planner’, and changed it a tiny bit to boost my productivity. I haven’t bothered with talking to upstream since it’s been unmaintained for years, but you can find patches attached to this post if you too need a quick planning tool.

As you may have seen, my time has been very limited since my previous blog article. Since my previous articles. I have mostly been busy writing my Ph.D. thesis, organising the XDC 2014, giving a few talks (most notably at Kernel Recipes 2014 and XDC 2014), defending the thesis and … moving to Helsinki/Finland!

Indeed, I got hired by Intel Finland to work on the performance of their integrated GPU on Linux! This work will mostly lead me to work on mesa-related project even though I will also help on the power management runtime front.

I am still in the process of settling down, finding an appartment and getting used to my new life so do not expect me to be highly available this first month. For this reason, I will not be able to attend FOSDEM this year…

Edit 20/01/2015: Found everything, should be up and running in the coming week.

You may wonder what this will change with regards to my current involvement in Open Source projects. Hopefuly, the next sections will answer most of your questions. If not, please send me a comment.

This post is a space to discuss some of the assumptions I make when thinking about the security of Linux. It’s aimed at being a quick reference so does not include extensive references to refeered papers and actual statistics, though I will at some point write a long version. I’ll update the post over time to clarify it.

Once Upon a Time

Trying my best to make the title sound like one of those tales you’d tell your kids when putting them to bed. Those who know me well know that I’m doing a PhD, allegedly on activity confinement, and those who know me even better have witnessed me rant every day for three months about how it’s impossible (because ethnomethodology, phenomenology, embodied interaction, situated action, etc.). So I decided to convert to another religion. I’m now a guru of the church of sandboxing. Hopefully neither cognitive dissonance nor my PhD advisor will catch up on me before my defense (ah ah).

There’s a plethora of tools for app sandboxing out there, on every major OS, and even more people arguing over which is the most secure – nothing I can convince myself to care about. Because all these sandboxing tools assume, in one way or another, that the thing they’re trying to contain is designed to be put in their box. This worldview fits server apps incredibly well: they’re designed to process one type of data, continuously, and to produce a specific output at a specific place for a specific input. Security researchers also got very wealthy exploiting the silicia nugget of mobile phones: phone apps have such little utility and phones such restricted interaction techniques that you never do any substantial multitasking or process any complex kind of data, you have fewer options for app customization than on the desktop, and as a result most mobile apps process their own data rather than your documents.

All of that is wonderful, but when you’re interested in general purpose multitasking-capable complex operating systems, it doesn’t work. Users tend to keep a lot of data around on their desktop OS, they have apps that process multiple formats and they reuse a file across multiple apps. They constantly multitask with apps that don’t care the least about proper password storage, etc. You’re even routinely asked to process data from multiple untrusted sources on a routine basis to earn your salary! And yet apps easily get compromised (especially Linux apps), and stay compromised afterwards. They can destroy all of your data, abuse your resources and steal your root password with surprisingly little effort!

It should be obvious to all that access control policies and “fine-grained” sandboxing are no cure to the disease of the desktop. If not, read field studies on information workers’ daily life, contemplate the sheer complexity of their work days and then come back and ask them if they want to sit and write policies because they get any work done. Our challenge is to have the policy be produced on-the-fly, and with no user cost (time, money or cognitive load) s’il-vous-plaît. Sandbox Utils is my collection of black magic tricks that do just that.

1. Introduction

After Martin published his article on the security on Wayland, we received plenty of feedback, and among it emerged a discussion on the difficulty of preventing the spoofing of authentication and authorisation dialogs (the former often being used as a by-product for the latter). Such dialogs appear either when you require a privilege escalation (gksu-like) or access to a restricted/privileged interface controlled by the compositor/desktop environment. In the system we envision, applications have restricted privileges and some are awarded special ones (such as the ability to record the screen, receive special keyboard input, etc.). When an app needs a privilege it does not naturally have, it must ask for it through an authorisation protocol. Besides, we also need to provide a means of authentication that resists spoofing, for the few cases where authentication remains necessary. In this article, I explore the threat model, security requirements and design options for usable and secure authorisation and authentication on modern Linux.

Errata: this article is not about when to use authorisation, but about how to design it. I perfectly concur to the view that the best permission request is the one that does not involve disturbing the user! The ideas discussed here apply for those few edge cases where we may not be able to design authorisation requests away (updated on 2014-03-28).

It’s been more than 3 years since my last security-related blog post. One might think I lost interest but the reality is that I just suck at blogging. This blog post is meant as a summary of a debate a few of us had privately and publicly on the Wayland ML.

Disclaimer: Although I try to be up to date with everything that surrounds security of X11 and Wayland, what I write in this article may be outdated, incomplete or simply blatantly wrong. This article being the basis for a document I’m planning on writing to help Wayland compositor developers implement secure compositors, I would love to hear your feedback!

Frama-C is a static analysis tool that does not just match “dangerous” function names or code patterns like RATS, and that does more than Splint’s memory management, control flow checks and reachability analysis. Frama-C uses abstract interpretation to analyse the potential values of variables and detect a whole other bunch of bugs in programs. It also provides a specification language to write assertions or pre-conditions on functions and prove that these assumptions hold. Frama-C is designed for correctness: it will report false positives (for instance fail to validate an assertion on the return value of a function) but never true negatives. It focuses on showing the absence of bugs, by proving assertions respect pre-conditions. This has applications in evaluating the safety of critical systems.

What interests us here is the combination of value analysis and slicing, as the slicing lab with my language-based security students this year was a bit… light! In my defence, I didn’t expect them to actually do their homework! We’ll work through combining value analysis and slicing on code samples, starting up with more basic aspects of Frama-C. This post is in its vast majority inspired from the contents of the Frama-C documentation. In particular, many code samples are taken or derived from the Value analysis documentation.

Update: I’ve received interesting feedback on this article from Julien Signoles, one of the many talented people behind Frama-C. I’ve amended/clarified some of the things I discuss in the post, mostly changing ambiguous vocabulary I used to avoid confusions. Julien also explained in more details some aspects of Frama-C which I had forgotten, and so I’ll try to inject his own wisdom into the original article. Thanks Julien!