// we are

Managing Authorisation and Authentication UIs in a Wayland-Based Linux

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).

Wayland Compositors - Why and How to Handle Privileged Clients! (Updated on the 2014/02/21)

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!

A Return Into the World of Static Analysis With Frama-C

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!

InfoSec RTFM: Password Expiration Policies

This post is the first of a hopefully irregular series of articles on the consequences, in the information security industry, of decisions not based on most recent research or even on basic threat modelling but on common sense faux-amis. Password Expiration Policies (PEP from now on) are quite widespread these days, and are justified by a various assumptions about attacker and defender behaviour. They consist of forcing you to change your password on a regular basis to access a service, often restricting syntactically similar passwords.

PEP may sound brilliant at first. However, a superficial economics overview and an attack/attacker breakdown of the problem help to understand why PEP do more harm than good in practice. Demonstration.

DIY Programmable Paper Lanterns #2

Hi there. This is a followup of the Programmable Paper Lantern project which I previously blogged about. Since the last time, I’ve found a much better cage design, ordered a first set of LEDs and a transformer for testing (with a more than DIY solution to power it, as you’ll see…) and I’ve, especially, made the design of the electronics that will be used in the final version. The last bit obviously happened with tremendous help from Martin, who went as far as offering me my first Arduino. And who also re-taught me the basics of electronics. Shame on me, the engineering graduate, but I must say I started almost from scratch on that, and I still know nothing but elementary survival notions.

WtRPM: A Web-based (Wt) Suite to Power Up/down Your Computers

Over the past last month or so, I have been working on creating the hardware and the software needed to be able to boot/reboot/hard reboot my computers at home. The reason I need this is that I am going away for a few months, away from my computers, and I would like to be able to keep on reverse engineering nvidia’s ptherm.

A possible software-only solution is to use Wake-On-Lan to boot up the computer remotely, ssh to connect to the computer, grub-reboot to select the kernel to boot on at the next reboot and finally, the watchdog to reboot the computer when it crashes. If it seems to you like a pain to use, I definitely agree!

So, a hardware-based solution seems more interesting! The standard solution to solve this issue is called IPMI. The interesting features are:

  • Being able to cut the power down and put it back up again;
  • Read back some of the state (Power & disk LEDs for instance);
  • Having a serial console.

However, I don’t have an IPMI-ready motherboard as they are usually used on servers. I thus decided to make myself an equivalent. The only thing that was worrying me was that I had to be able to control that from the internet. So, one machine had to be up and running! I decided to buy a Raspberry Pi as it was the cheapest and lowest-power consumption computer I could get with an ethernet port and a few General Purpose Input/Output (GPIO).

Using those GPIOs, I can control a custom-made circuit board to cut the power, press the power switch and read the power led state but the real question was about the user interface to wrap those GPIOs. I decided to make a web-based user interface because it was more demo-able and also could be updated in real time for displaying logs and the power LED state.

DIY Programmable Paper Lanterns or Why I Should Be Worried About My Impulsiveness

Hey. Been a while. Since the last time I posted, I graduated from two universities and moved to London. Life passes fast, huh? But hey, this is not a rant about the weather, food, cultural differences, the superficiality of relationship in big cities, expensive hockey rinks or whatever. Note how I’m not even pretending any more that I’m gonna tell you in the next post about that super cool thing I’m working on at the moment!

Instead, I’m gonna tell you about paper lanterns! Hey! Hey, no, wait! Hold on, don’t leave! Just a sec! We’re not speaking about your average paper lantern here! The goal of this project is to combine traditional and modern, handcrafted and digital, in short… to make a bunch of programmable paper lanterns!

WtComments: A Secure Way of Serving Comments on Static Blogs!

As a new proud user of Octopress I missed the comment section that I used to have on our previous blog (powered by Django). However, I knew something could be done and months later, I finally did something about it :).

So, let me introduce you to Wt Comments:

Wt Comments is a project that was written in order to allow users to comment on static websites (such as The goal was to create a secure, minimal and self-standing binary that would serve user’s comments as needed. These comments are to be stored in a JSON file.

I wanted a program that would run under a specific UID (using FCGI or a built-in http server) and that would provide strong separation between code and data in order to limit the risks posed by this service to the system. I decided to write this project in Wt, a C++ Web Framework that I have been looking into using for a while now, because it satisfied all my pre-requirements and allowed the usage of hardware and gcc security features such as the NX bit and canaries.

The program has been written with portability in mind. However, it is currently limited to Linux due to one simple function (getExeDirectory()). Feel free to send me patches ;)