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.
What Computer are we Speaking About?
I am designing for desktops, laptops and tablets – not for phones (which are used only for a subset of activities which I see as having lesser security needs). I design for productive and recreational users – not for occasional users who have very basic needs, because I find it easier to accomodate those on a UI that offers complex features and shortcuts than to accomodate productive types on limited UIs. You’ll guess that my focus is on multitaskers, work and home settings, and security rather than merely privacy.
Types of Devices
- Desktop (interactions based on keyboard + mouse)
- Laptop (keyboard + mouse, a little bit keyboard-oriented)
- Tablet (touch + virtual keyboard, touch-oriented)
- Mobile Phone (touch + small virtual keyboard, touch-oriented and keyboard-averse)
Whilst there is a temptation to go all-touch these days, this just kills the efficiency of the UI for anyone who does have a keyboard. I appreciate cleaner UIs which work well with touch, but that shouldn’t mean that all keyboard-navigation shortcuts (such as immediate access to the location bar when opening a file) should disappear.
A well-designed UI accomodates fast touch and fast keyboard navigation.
I’d also like to point out that Tablet/Phone OSes have an app model based on massive privacy violations. There is no indication that an open OS with apps that do not pay for themselves with data theft and resale would gather any developer audience.
Types of Users
- Productive (absolutely all complex tasks and workplace usages)
- Recreational (typically personal computer of any kind)
- Data consuming (e.g. phones where the only value is ads+online shopping)
Productive users basically all workplace practices; anything that requires using complex/specific apps that manipulate data in complex ways, and usually those users have lots of heterogenous data. If you think this type no longer exists, ask yourself whether people manage client profiles, do graphic design, type reports, write programs, produce videos, manage the schedule of a company, do accounting, etc. on a mobile phone. Productives multitask a lot. They handle sensitive or at least valuable information routinely and they need security to just work. Often they have no patience for security mechanisms that require attention and for permission prompts as these make them lose a lot of work time. Productives need to get the job done, and so they need shortcuts, good defaults, and apps that do their job without tweaking.
Recreational users are much closer to data-consuming. It’s the people who use a device of any type for multiple but relatively easy/passive tasks, such as reading news, listening to music, watching videos, chatting on IM or social network apps, playing basic games. These users have maybe less heterogeneity but can have very large amount of music/photo/video files. They may occasionally need to be productive with their machines (writing a CV, etc.) though it’s not a day-to-day use case for them. Recreationals enjoy windowed environments designed around multitasking, they can switch easily between their web browsing, social networks, IMs, movie watching, etc.
Data-consuming users are the users who exclusively do simple things, mostly online or on-the-cloud, and don’t really have files. These are typically mobile users. Data consumers are maybe less prone to multitasking because they actively engage with the app they’re using, or because their UI is more centered on displaying data than on providing controls and shortcuts for complex tasks. Some of these may have a very limited usage of computers, whilst some others could well be recreationals that just delegate any productive task to separate devices or even other people because their mobiles don’t answer their productive needs. Mobiles have simple UIs where data consumption can be made straightforward and more convenient than on heavier devices (via more specialised apps and better integration between major web content providers and apps), but it’s not easy to get any work done on these machines. A typical symptom of these data-consuming devices is the prominence of the “Mark as Unread” button on mobile email apps – you can easily read your emails but it’s so painful to write them that you’ll do it elsewhere.
If you’re designing a general-purpose desktop environment only with the data-consuming people in mind (and thus forcing other categories to adapt mouse-based interactions on unscalable interfaces), you’re probably making a mistake. The rise of mobile devices does not mean people all of a sudden dropped their desk job across the globe. It simply means that people who had never needed a PC in the first place don’t buy PCs anymore. Mobiles will probably never cater for all those complex jobs that require you sitting in front of a screen 8-12 hours a day. Hence, intensive users who need to get a job done should still be part of your target audience, and your designs should scale up to their needs.
The Threats Linux is Facing
I’m not a malware expert but I have a good grasp of how the industry works. Things are not as pretty as you’ve been told when installing your first Linux, and both Windows and OS X are significantly more secure than a desktop Linux nowadays We still have no OS-provided app sandboxing (even for apps who want to sandbox themselves). What we have right now is far from easy to use, and app devs cannot bundle their apps so that they can be transparently sandboxed. The only examples of relatively sandboxed apps are Chromium and Firefox, both using their own solutions since none is provided on modern Linux distros. In contrast, both Windows 8 and OS X have an API for userland apps to restrict their privileges. We’re also missing graphic stack security, though this is obviously going to change with Wayland.
People often claim that Linux is protected from malware. This is false. Commodity malware vendors support OS X with only 5-8% market share. Our time will come at some point because the malware industry is very professionalised and the Linux market is one among few that are left to be conquered. In fact Advanced Persistent Threat malware authors do support Linux, as suggested by the analysis of The Mask. This one has been around since 2007.
I’ve played a few years ago with the Adobe XXE attack.
It is said in CVE-2005-1306 that one can only discover file names with XXE attacks on Acroread 7, but
I rewrote the exploit showcasing the theft of system config files based on this principle, and even
with SELinux enabled and a default policy, I could steal some /etc files that were
allowed by audit2allow, sometimes including /etc/passwd – because writing the strictly minimal policy for any app, especially proprietary ones,
is so utterly complex, you’ll probably still find some data to gnaw on with your exploit. Nicer exploits could allow proper
remote code execution and hence theft of absolutely all documents that the PDF reader has access to.
I’ve also fuzz-tested evince a bit for teaching purposes and it’s clear to me that there are many low-hanging fruits waiting to be exploited by black hats, because FOSS apps crash too often, too easily, and some of the crashes produce invalid writes that probably contain a handful of buffer overflow or format string vulns.
In short: Linux is attackable and most of the FOSS apps that we all trust are excellent attack vectors. Crafted downloads are one of the most common attack vectors for the productive types (see the Verizon DBIR 2013, I’m still reading the 2014 one), so one cannot assume that even a PDF reader is safe to use, and that even a PDF reader written by your friends at the GNOME Foundation can legitimately have access to all your PDF files at any given time.
We need as many apps as possible to have access only to what they’re using at the time they’re using it, because otherwise we’ll take a huge blow to the face on the day Linux exploits are first noticed – at that time Windows and OS X will probably have all apps sandboxed by default and we’ll look like idiots – which is a shame since sandboxing on other platforms is still clearly suboptimal at the moment.
Desktop Capabilities
See my post on authorisation UIs: things like clipboard management, screen capturing, etc. could be enabled by default for one Desktop Environment provided app, so that users can use the system out of the box. However, other apps that occasionally need a capability and are not explicitely trusted by the user should obtain permissions per-session, by:
- displaying a system-provided UI element whose activation indubitably indicates user authorisation
- trigerring a one-time or session-long permission prompt
Who Should be Trusted by End-Users?
The following cannot be avoided, because they write and provide all the privileged OS components:
- Linux and driver developers
- Distributors and their core packagers (Red Hat, Debian, Arch)
- Desktop Environment developers (KDE, GNOME, XFCE core devs)
However, app developers and packagers are not trustworthy. There’s no evidence that the hundreds of app packagers all have security training and can evaluate properly whether an app is resilient enough to be granted a capability or default access to a large chunck of the user’s assets.
I don’t see the point in making a distinction between FOSS and proprietary devs here, and would rather segregate between people who already need to be trusted and have some staff responsible for security and people who cannot be clearly identified and whose security competence cannot be assessed.
What and How to Sandbox
In conclusion, I’d rather take a rather drastic approach to sandboxing and see what can be designed under that view. It’s probably better to lower security a bit on some components that to merely provide illusory security because of potential complexity issues. Here is what I want to achieve:
- all apps should be sandboxed – core DE components that may easily be exploited should be sandboxed when possible
- sandboxed apps should have access to almost nothing when launched
- the best way to give access is a seamless, trusted-path-based user interaction; APIs should be crafted to make such UIs robust to attacks by apps
- apps output data either via a legacy file system or sharing mechanisms that expose a wider range of stores in a secure fashion
- exceptionally, DE-provided apps have default permissions for the sake of good UX; DE devs can compensate with stringent security testing
It’d be really great if others who are interested in app sandboxing explained what goals they want to achieve, for which users and based on which assumptions. It’d be great if our goals were identical, but also if we could just keep other use cases in mind when we can make decisions that fit a larger audience than ours. What I find interesting is that apart from the target audiences that we have, it seems most people have the same security requirements list! I’ll include links to other similar documents below in this post.