de Nittis Ludovico’s blog

After GNOME Security Internship - Update 7

2019-04-24T16:00:00+00:00

Here you can find the introduction, the update 1, the update 2, the update 3, the update 4, the update 5 and the update 6.

Part 1, protection from unwanted new USB devices

I received a few code reviews in the GNOME Settings Daemon MR that I’ll try to address in the next days.

Also I’m going to widen the requirements for allowing keyboards when the screen is locked. Right now if the lock screen is active we authorize a keyboard only if it is the only available keyboard in the system. It was a good idea in theory but not that much in practice.

For example let’s assume that you use an hardware USB switch hub between your desktop and your laptop with a mouse and a keyboard attached. If you have a “gaming” mouse with extra keys it is not only a mouse but also a keyboard. That means that when you want to switch from your laptop the the desktop, the mouse and the keyboard will be connected nearly simultaneously and if the mouse goes first the real keyboard will not the authorized. So you’ll be locked out from your system.

The gaming mouse is also only an example. If you have a yubikey shared in this USB hub there will be the same problem explained above.

For this reason in the next days I’ll edit the current implementation so that every USB keyboards will be authorized even if the lock screen is active. However we will still show a notification to explain that we authorized a new keyboard while the screen was locked.

Security at the expense of usability comes at the expense of security.

-AviD’s Rule of Usability

Part 2, limit untrusted USB keyboards

At the beginning of this month I started to work for Collabora and they allowed me to continue this GNOME project in my R&D time!

So thanks to that I made some interesting progress:

I added the required new GSetting to enable/disable the keyboard protection in gsettings-desktop-schemas
I experimented with the kernel key masking EVIOCSMASK. It worked very well with just a couple of issues still to address. Anyway after these tests I came to the conclusion that maybe the key filtering in the userspace is a better solution for this usecase. For example in the future it will be easier to add extra functionalities like showing a system notification when a not authorized keyboard sends a dangerous key.
In Mutter previously when we needed to check if a key was in the dangerous keys list we used a binary search. But the dangerous keys list is static so I removed the binary search in favor of using an hashset. Even if the performance gain is negligible, we can now perform a search in O(1) instead of O(log n).
Last time I did a benchmark it was when we used a device hash with name, vendor and product id instead of using the udev property as we do now. So I redid it and I’m glad to see that in the worst case scenario the delay of a key press halved.
Instead of using hwdb we store the device authorization in a local db and we use an udev helper to import the rules from the db. In this way the udev rule will always be static.
I completed the integration with GNOME Control Center. Now there is a working lock/unlock button to gain admin privileges via polkit. When the user changes the authorization level of a device it gets stored in a local db and we trigger an udev reload echoing “change” into the “uevent” sysfs attribute of the device. This new panel is also hidden if there isn’t a wayland session (the mutter key filtering works only on wayland).
I opened the necessary MRs upstream to gather feedback from the community. GNOME Control Center MR, Mutter MR, GSettings Desktop Schemas MR.

Benchmark v2

Now that we simply check if a device has the udev property GNOME_AUTHORIZED I did another benchmark:

Mutter stock: 1-2 usec to compute the pressed key.
With keyboard security off: 1-2 usec. It’s just an extra if check.
With keyboard security on: 1-2 usec. An extra if and a search in the hashset of “dangerous” keys.
Keyboard security on and you press a “dangerous” key: 4-6 usec. In this case we also need to check the udev properties of the device.

Compared to last time, the worst case scenario execution time dropped from 7-12 usec to 4-6 usec.

GNOME Security Internship - The end?

2019-02-28T13:15:00+00:00

Here you can find the introduction, the update 1, the update 2, the update 3, the update 4 and the update 5.

The end? Is the internship already ended?

Yes, incredibly these three months went by so fast. It was an awesome experience, so I’d like to thank the whole GNOME Foundation for giving me this opportunity.

What’s the project status?

The first part regarding protecting the system from potentially unwanted new USB devices can be considered completed. Probably now it will requires just bug fixing and minor changes, if necessary. The required merge requests are up.

The second part regarding limiting the number of usable keys for untrusted keyboards reached a working stage. However it’s still under evaluation which is the best way to achieve it, because even if with the current solution works it doesn’t mean that this is the desirable way to do it.

What will happen from tomorrow?

Even if the internship will be officially ended I’m still pledged to carry on these two features until they’ll be merged in upstream.

Right now I’m actively searching for a job (preferably in the open source world), so in the next few days I’ll still be able to spend a considerable amount of time in this project, at least until I find a full time job.

GNOME Control Center USB protection switch

Old:

New:

As I mentioned in the last blog post we realized that the always on USB protection was marginally better (or worse) than the protection with lock screen. So we decided to leave in Control Center only an on/off switch that by default controls the USB lock screen protection.

If necessary it’s still possible to enable the always on protection editing the usb-protection-level desktop schema.

This UI change allowed us to remove the ambiguous protection on switch with the drop down protection level “never block”.

Now when you disable the protection from Control Center, in USBGuard we set InsertedDevicePolicy to apply-policy and we add an allow everything in the rules file. In this way we try to leave USBGuard in a clean state. From there USBGuard will never block USB devices anymore. You are then free to leave it as is or, if you want a stringent or different protection behaviour, use a third parties GUI or even write your own script to handle USBGuard.

Limit untrusted USB keyboards

Finally in this front we reached a first working implementation.

In the new Control Center tab we show an on/off switch and a list of currently plugged in keyboards. This list is automatically updated when keyboards gets added or removed.

We store the authorization property with hwdb. In this way we can bound it to a specific device product and retrieve this information directly from libinput.

When a new keyboard is added it is limited by default until you manually set it to be fully trusted.

While this implementation is working as expected, we are currently evaluating other alternatives.

For example in mutter every time we receive a new keystroke we check if it is a dangerous key. As an alternative we could use the kernel EVIOCSMASK instead.

Another thing that we are evaluating is if we should replace the hwdb with another db created ad-hoc for this purpose.

What to expect next and comments

In a couple of weeks I’ll return hopefully with a few interesting updates regarding the untrusted USB keyboards.

Feedback is welcome!

GNOME Security Internship - Update 5

2019-02-15T13:45:00+00:00

Here you can find the introduction, the update 1, the update 2, the update 3 and the update 4.

Always on protection vs lock screen protection

This project started with a simple on/off switch in control center that entirely enabled or disabled the USB protection. A respectively so called always on and always off.

Later on we introduced a smarter protection level that was active only when the user session was locked.

While an always on protection seemed a good idea on paper it turned out that the advantages compared to the lock screen protection were very slim.

When the screen is locked both protections have the same behaviour. They only differentiate when the user session is unlocked.

With “always on” protection you are covered even when you leave your pc unattended and unlocked, right? Well, not really. The protection level is configurable from Control Center without root access (because we can use USBGuard’s D-Bus with user privileges). This means that if you leave your pc unlocked an attacker could just disable the protection and then plug his malicious device. With this in mind, the always on protection can give us more troubles than benefits (angry users that can’t plug their devices).

So should we completely remove the always on protection?

From GNOME Control Center probably yes.

But there are use cases where the always on protection can still be useful, like in a kiosk setup where you never expect USB devices to be plugged in and where the users can’t reach Control Center. So probably we will keep this protection level only as a gsetting option.

How to show the lock screen protection on GNOME Control Center

Dropping the always on protection will leave us with just the lock screen one. It means that we can simplify the dialog on Control Center. Instead of a dropdown menu we can just show an on/off switch, similarly to what we had in the early proof of concept for this project.

Protection enabled by default?

There is a currently ongoing discussion about enabling the USB protection by default. This is also for example what is starting to happen with ChromeOS (I’ll talk about it below).

If we enable the protection by default, can we remove it from Control Center?

Probably not. Even if we have this option enabled for everyone, some users may still want a custom USB protection behaviour. For example they could use a USBGuard GUI or manually edit the USBGuard configuration. In this case we can’t also interfere and mess with USBGuard configuration.

So we still want to give users an easy way to manually manage USBGuard or even disable it completely.

If this option should be exposed from Control Center, or only with a gsetting, is something that probably we still need to evaluate.

ChromeOS update

In the project wiki page we mentioned that ChromeOS was going to integrate USBGuard support. Now it already landed in the Canary channel and can be enabled with the flag chrome://flags/#enable-usbguard. In the future probably it will be enabled by default.

To understand ChromeOS approach I checked their source code and this is a quick summary of what I found:

When the screen is not locked USBGuard daemon is stopped/killed.
When the screen gets locked USBGuard daemon is started with a custom rules.conf file.

What’s inside rules.conf? I.e. what type of devices are blocked?

allow with-interface one-of { 03:00:01 03:01:01 } # Whitelist keyboards.
block with-interface one-of { 05:*:* 06:*:* 07:*:* 08:*:* } # physical, image, printer, storage
allow

This can be summed up as “allow everything except for physical, image, printer and storage USB classes”.

In what our solution differs?

The first main difference is that we edit USBGuard configuration to let it run even when the lock screen is off. In this way we don’t need to stop and start it after every lock screen change of state.
The second difference is regarding the whitelist. Currently to prevent locking out users when their main keyboard breaks we allow a new one if, and only if, it is the sole currently available. ChromeOS instead does a wider whitelist on all keyboards.

Apart from the two differences highlighted above I think that it is good to see that they are using a similar approach to the one we have right now–i.e., block new USB devices when the session is locked.

First UI PoC for keyboards protection

In the keyboard protection front (block dangerous keys for untrusted devices) this is the first Control Center UI concept that I realized. Keep in mind that this is still heavily a work in progress. This interface is just the first iteration.

Where to store if a device is authorized or not?

One possibility is USBGuard itself. When we grant a device full access we may store it in USBGuard’s rule file. With this approach we will be able later to access this list using the D-Bus method listRules.
Another possibility is to create a custom DB (maybe a plain text file) where we will store these information.

Right now mutter (more precisely from clutter) is where we really drop the dangerous keys for untrusted devices. So we also need to think about how to access this whitelist from there.

As a first implementation we will probably generate an udev rule with the hwdb file. In this way we will be able to access the authorization property from libinput, without the need of a D-Bus call.

What to expect next and comments

I’ll edit the gnome-control-center MR to reflect the fact that we don’t need anymore a dropdown menu. Also hopefully before the next update post we will be a step closer to reach a production ready keyboard protection.

Feedback is welcome!

GNOME Security Internship - Update 4

2019-01-29T17:00:00+00:00

Here you can find the introduction, the update 1, the update 2 and the update 3.

Graphical recap

After 4 long posts talking about USB devices, lock screen and keyboards are you a bit lost? Are you trying to find an answer to the question: “What will happen when I plug a USB device?”

Don’t worry, I’m here to help you with an easy to follow flowchart.

GNOME Control Center, USBGuard version check

In our implementation we use functionality that are available only from USBGuard 0.7.5. In reality the last version of USBGuard is the 0.7.4, but the changes that we need are already in master. So to be more precise, we require a version newer than 0.7.4.

Because USBGuard will most likely be an optional dependency, how do we check if the running version is new enough? Given the fact that the new version of USBGuard has an additional get/set method for ImplicitPolicyTarget, I added a check to GNOME Control Center where I try to get this parameter. If it fails it means that the running version of USBGuard is too old.

The time has come. Merge Requests!

After a call with Georges Basile Stavracas Neto and Benjamin Berg we agreed that probably the best way forward was to create the required merge requests as early as possible. Even if we will probably aim for an inclusion in the GNOME 3.34 cycle, doing it now will facilitate the gathering of feedback for the actual implementation and, maybe even more importantly, feedback for our design choices.

So this morning I prepared the required merge requests.

gnome-settings-daemon tests

I wrote a couple of tests for the USB daemon. The first is about testing the configuration sync between gsettings and USBGuard. The second checks if the “allow everything” rule gets added correctly to the USBGuard configuration.

They work but the code is still ugly. So right now they are not included in the MR that I did. After a cleaning and another correctness check I’ll be able to do so.

Progress on the second part, the keyboard’s dangerous keys

Right now I added a keyboard protection entry in gsettings. I’m not 100% sure if this will be the best place where to store it, but is good enough for starting. And also, if necessary, it will be easy to change it later on.

I did a first implementation on Mutter and so far is it working as expected. When we receive a key input event we check if the protection is active. If it is we check if the pressed key is a dangerous one. If that’s also true we generate a sha256 hash starting from the device name, the vendor id, the product id and its serial number.

Then we will be able to match this hash against a whitelist/blacklist database.

I’m also working on presenting these information on control center. The first step is a tab similar to the thunderbolt one, where we have a general toggle to enable/disable the USB keyboard protection and then a list of known devices with their current permission.

I’ll try to not use too much time on this first implementation of control center because it will be more a proof of concept and a base to better understand how to store persistent devices information and how to pass them to mutter.

And the performance?

While I wrote the key handling on mutter I asked myself: “and the performance?”. I was really curios about it, so I added a timer around the key handling method in mutter and I timed how much my additional check affected the performance.

Mutter stock: 1-2 usec to compute the pressed key.
With my modification with keyboard security off: 1-2 usec. It’s just an extra if check.
With keyboard security on: 1-2 usec. An extra if and a binary search against an int list of keys.
Keyboard security on and you press a “dangerous” key: 7-12 usec. In this case we also need to compute the sha256 of the device.

For prospective, the best consumer monitors available right now have an input lag of 9-10ms, while an average monitor can take 30ms or more. This site has been used as a source.

Keeping in mind that 1 millisecond (ms) is 1000 microseconds (us), I’m pleased to see that even when we need to generate a sha256 hash the performance hit is negligible.

FOSDEM

This weekend I’ll attend the FOSDEM event. So if you want to talk a bit about this project I’ll be there.

On Sunday Tobias Muller and me will have a talk where we will present this project.

What to expect next and comments

Hopefully by the next project update we will have a working first implementation of “limit keyboard capabilities” with all the required pieces together.

Feedback is welcome!

GNOME Security Internship - Update 3

2019-01-14T15:25:00+00:00

Here you can find the introduction, the update 1 and the update 2.

Notification if you replug your main keyboard

As of now we allow a single keyboard even if the protection is active because we don’t want to lock out the users. But Saltarelli left a comment making me notice that an attacker would have been able to plug an hardware keylogger between the keyboard and the PC without the user noticing.

To prevent this now we display a notification if the main keyboard gets unplugged and plugged again.

Smart authorization with touchscreen

If your device can use the touchscreen and your physical keyboard breaks you should be able to use your device because you’ll have a working on-screen keyboard. Because of this I added an exception to the auto authorization of keyboards if touchscreen is also available. Thanks to Marcus for this hint.

GNOME Shell protection status

Now GNOME-Shell shows an icon in the status bar only if the protection is really active. In order to reliably test it we check both the gsetting protection value and also if the USBGuard DBus is really up and running.

As shown in the screenshot below we are currently using a generic “external device” icon. Before the final release we should change it, hopefully with an external help :)

GNOME Control Center

GNOME Control Center before showed just an “on”/”off” label next to the “forbid new USB devices” entry. Now a more informative label has been added. In this way we can show directly the protection level in use.

On top of that, we also check for the USBGuard DBus availability. If it is not available we show the current protection level as “off” and we prevent the users to interact with the USB protection dialog.

Limit keyboards capabilities

As I said briefly in the last update, the goal here is to prevent new keyboards from using dangerous keys (e.g. ctrl, alt ecc…).

At the beginning I tried to experiment with scancodes. One possible approach was to append to the hwdb an always limit rule like this:

evdev:name:*:dmi:bvn*:bvr*:bd*:svn*:pn*    # Matches every keyboards
    KEYBOARD_KEY_700e0=blocked             # Block left ctrl
    [...]

Then when we wanted to grant full access to a single keyboard we appended a device specific rule (vendor, product, version ID and input-modalias of it) mapping back every previously blocked keys.

While at first this seemed a feasible option, after a few emails and a call with Peter Hutterer and Benjamin Tissoires we decided to discard it in favour of a device grabbing with EVIOCGRAB/libevdev_grab().

For example one problem with scancodes mapping using the hwdb was that the matches were not predictable if there were multiple of them applied to a single device (first the always block and then the permission granted).

EVIOCGRAB and Mutter

The route we are taking is to implement the key filtering directly in mutter (my early work on it). As soon as we have a new device we take the grab on it with EVIOCGRAB, in this way we will be the only one that can see the device key events. Then when a key gets pressed we check if it is a dangerous key. If it is we drop it.

With this approach for example we still can get notified when a dangerous key is pressed (as opposite to the scancodes approach). In this way we can display a notification saying that the device is limited, so nothing happened because a key has been blocked and not because the keyboard is broken.

How to handle this in the UI is still under discussion and evaluation. Maybe we can start with showing a list of connected keyboards in GNOME Control Center. Next to every entry in this list we could put a colored icon to show the current device status. That is could be either limited or full access. Then the users will be able to toggle this icon changing the specific device permission.

What to expect next and comments

In the next days I’ll try to refine the “limit keyboards” functionality and I’ll try to come up with a way to expose this feature to the end users. Also related to the smart authorization, we should also check for other input devices like keyboards on the legacy PS/2 port.

Feedback is welcome!

GNOME Security Internship - Update 2

2018-12-31T15:35:00+00:00

The introduction and the first update can be found here and here.

Allow one keyboard even when screen is locked

Let’s hypothesize that you choose to protect your PC from new USB devices when the lock screen is active. USBGuard does its job and every USB devices plugged with a locked screen gets blocked. The key word here is every.

What if your keyboard breaks? You go to your garage searching for an old working keyboard. After 15 minutes of searching, you find it and you return to your PC. The screen is now locked because the automatic timeout passed. You plug the new keyboard but it doesn’t work, because the screen is locked.

You could do a reboot but in this way you’ll lose all your unsaved work.

In order to gracefully handle this situation we added an exception to the block rule. Now if you plug in a keyboard we authorize it if, and only if, this is the only one currently available.

And what if an attacker disconnects my keyboard, plugs his infected device and then reconnect my keyboard? In this scenario the attacker device will be authorized (if it advertise itself as a keyboard), but then the session would be still locked. So he needs to reconnect your keyboard too, because he needs to wait that you return in order to unlock the PC. But when he reconnects your keyboard it will not be authorized because it is no more the only available keyboard in the system. Also because we don’t permanently store a list of whitelisted devices. So when you replug a device it will be treated as new, like it never saw it before.

In order to check if the plugged device is a keyboard we check if the USB class is “03:00:01” or “03:01:01”, as described in the USB specs.

Are there currently some problems to this? Unfortunately yes, because it’s not everything black and white. This method works very well until your “gaming” programmable mouse also advertise itself as a keyboard. In this scenario we do not authorize your replacement keyboard because we see that there is already a working one.

In the end this solution definitely improves the situation, while in the future probably it could be revised and tweaked a bit more.

Initial work regarding a “smart” always block.

This is something still in its early stage. In a first version, if the screen is not locked and you plug a keyboard the screen will be locked.

This works good in theory but not in practice, because not only devices with physical keys are keyboards. For example the devices for hardware 2FA (e.g. yubikey) are also keyboards, and locking the screen every time you plug one of those is not a pleasant experience. So for a first implementation this solution is ok, but it definitely needs to be improved.

One way to do it can be by mapping scancodes to keycodes, limiting particular devices capabilities (e.g. prevent them to use risky keys like “alt” or “ctrl”). Anyway this will require more research about what we can do and what’s the best way to do it.

How do we notice USBGuard configuration changes?

Before this part was handled by GNOME-Control-Center (g-c-c). Meaning that it had the job of keeping in sync what we had in gsettings and the internal state of USBGuard. But this was a problem if, for example, the user manually changed the USBGuard configuration while g-c-c was closed. We would have noticed the change only at the next g-c-c opening.

Refactoring!

In order to solve this a quite substantial refactoring happened. Now we have:

GNOME-Control-Center: part of its logic migrated to GNOME-Settings-Daemon. Now it just syncs with the gsettings schemas and doesn’t talk anymore directly with USBGuard.
gsettings-desktop-schemas: as before we store here under org.gnome.desktop.privacy the desired USB protection level.
GNOME-Shell: previously g-s had the job to authorize new USB devices, mainly because this was the only component that was always running. Now g-s is just used to display an indicator icon when the USB protection is active.
GNOME-Settings-Daemon: this is the new entry, now we have a daemon always running. It has two jobs, it keeps in sync the USBGuard configuration with the schemas on gsettings and also it is the one that authorizes new USB devices.

Enable and disable USB protection

From GNOME-Control-Center we give the user the ability to set the protection level to:

“Never”: meaning that you don’t want any sort of protection. You want every new devices to be authorized.
“When lockscreen is active”: meaning that you want the protection only when the session is locked.
“Always”: meaning that you always want the protection.

With “never” we set USBGuard’s InsertedDevicePolicy to apply-policy and we prepend to the rule file allow id *:*.

Good, but what if I want to manually configure USBGuard and I don’t want GNOME to mess anymore with my config, how do I do it?

To handle this scenario we added a more explicit on/off switch to g-c-c. “On” actually means “I want GNOME to handle USBGuard”. On the other hand “off” means “I want to handle USBGuard by myself”.

What to expect next and comments

In the next days I’ll try to improve the always on protection. Also I need to add a more robust way to check if we have a working USBGuard on the system. I’ll also do some extensive testing, trying to check the behaviour with different environments and scenarios.

Feedback is welcome!

Happy new year!

GNOME Security Internship - Update 1

2018-12-13T10:05:00+00:00

If you missed it, the introduction to this project can be found here.

Check if we are in a working state

Before letting the user select the desired level of USB protection, we check if we are in a working state. Meaning for example that USBGuard needs to be installed and the corresponding DBus service needs to be active.

If these conditions are not met, we grey out the dropdown menu in GNOME-Control-Center.

This method probably can be improved showing also the reason of the non working state to the users.

“allow” wildcard rule

As I mentioned in my previous blog post, we can’t get or set ImplicitPolicyTarget from the USBGuard configuration. While the PR is still open, we worked around this issue using the rule file.

Prepending a wildcard allow rule allow *:* we are now able to reach a state where every new inserted devices are automatically allowed.

It works like this:

If you set the protection level to Never, GNOME-Control-Center (g-c-c) sets InsertedDevicePolicy to apply-policy and add at the beginning of the rule file allow *:*. In this way when a new USB device is plugged:
1. USBGuard checks InsertedDevicePolicy. Because it is set to apply-policy it goes to the step 2.
2. USBGuard checks the rule file for a matching rule. allow *:* matches, and so the device gets authorized to work.
If you set the protection level to Always, g-c-c sets InsertedDevicePolicy to block. When a new USB device is plugged:
1. USBGuard checks InsertedDevicePolicy. Because it is set to block the device gets blocked without checking the rule file.

Fail-safe mode

Using the allow wildcard is also useful for reaching a fail-safe mode when we want USB protection when the lock screen is active. What does fail-safe mean? Let me give you a real world example:

The user sets the USB protection level to “when lock screen is active”, so when the session is unlocked he can freely plug in USB devices. But when the session gets locked all new USB devices needs to be blocked.

The logic here is bounded in GNOME-Shell’s lock and unlock functions. When a lock happens we set InsertedDevicePolicy to block. When the session is unlocked we set InsertedDevicePolicy to apply-policy.

But what happen if the user activates the lock screen and then GNOME-Shell crashes? After a reboot InsertedDevicePolicy will continue to be at block, so is the user locked out? No because there is a trick.

When USBGuard service starts there is another config variable that gets checked: PresentDevicePolicy. This rule regulates how to handle already connected USB devices. By default it is set to apply-policy, meaning that it will check the rule files and, if there isn’t a match, the ImplicitPolicyTarget value. And because we have an allow *:* in our rule file, already present devices will get authorized.

Oof, there is a lot in this section. But there is one last thing. Ok, we are not locked out because we can still use our plugged in, at boot time, USB devices, great. But what about InsertedDevicePolicy? It is stuck to block while it should be at apply-policy, how we reset it now? If you end up in this situation, you can invoke the lock screen one single time and everything will return as it should.

Reflect manual user changes

USBGuard can now be configured from GNOME-Control-Center, awesome. But what happens if I set something from g-c-c and later I manually edit the USBGuard configuration within the CLI or DBus? In order to reflect the current USBGuard status we subscribe to the new PropertyParameterChanged signal. If the protection level was “Always” but InsertedDevicePolicy gets changed to apply-policy, or also the other way around, if the protection level was “Never” but InsertedDevicePolicy gets changed to block, it’s save to assume that the user manually changed the USBGuard configuration. So we change the displayed value accordingly (without further changing the current USBGuard config values).

Notification for blocked USB devices

If a new USB device has been blocked because plugged in when the session was locked, we display a notification to inform the user that he needs to replug his device.

Step 3 - From static to dynamic

Until now everything has been achieved with a “static” configuration of USBGuard. That means that we edited USBGuard in order to let it do what we wanted, but we were not actively listening to USBGuard events, like to the signal DevicePrecenceChanged.

With this static configuration we probably can’t do much else, we reached the capability limit. This is the reason why now everything has been switched to be more dynamic.

Now the new GNOME-Shell’s USB component, similarly to the Thunderbolt one, actively listens to USBGuard signals and act accordingly.

What to expect next and comments

The two major things to expect are: smarter way to handle keyboards even if the protection is active (what happens if my keyboard breaks?) and also trying to add some sort of protection even when the session is unlocked (improving in this way the “block all” that we have right now).

Feedback is welcome!

GNOME Security Internship - The Beginning

2018-11-28T13:45:00+00:00

Introduction

For this very first round of GNOME Internships I’ll work in the USB Protection project.

The attack surface of USB is quite large and while disabling USB altogether solves the problem, it creates other. As do existing protection mechanisms. They suffer from poor usability and missing integration into the operating system.

This is why here we are trying a different approach to defend against rogue USB devices for a GNOME-based operating system.

USB is arguably to most exposed interface of a user’s machine. It allows an attacker to interact with pretty much any driver, many of which are of questionable quality.

In order to protect the users, while keeping the entire system easy to use, we try to be smart about when to allow new USB devices. First, we try to detect when the user is present, arguing that if the user is not then new USB devices should not work. But even this apparently simple case can hide some complications, because for example you might very well want to attach a new keyboard in case yours breaks. Keyboards, however, pose another risk as several attacks have shown.

This project will be handled with an incremental build model, decomposing the whole problem in parts. In this way we’ll be able to start tackling the problem from the easier cases and gradually increase the proposed solution complexity.

USBGuard

In this “preparation” month I started to look into USBGuard, because it is very likely that this will be the component we will use within GNOME in order to protect the USB ports.

The configuration of USBGuard consists of two files: usbguard-daemon.conf and rules.conf. The former holds a few variables like InsertedDevicePolicy and ImplicitPolicyTarget, while the latter is a file where it’s possible to whitelist/blacklist single, or groups of, USB devices.

When you plug in a new USB device in your system, USBGuard performs a few sequential checks in order to decide if a device should be enabled:

From the usbguard-daemon.conf the value of InsertedDevicePolicy will be checked:
- If it is apply-policy it will go to the step 2.
- If it is block or reject the device will be, respectively, deauthorized or removed. No further checks will be performed.
The rules.conf file will be parsed:
- If there is a rule that matches the inserted USB device it will be applied. No further checks will be performed.
- Otherwise it will go to the step 3.
From the usbguard-daemon.conf the value of ImplicitPolicyTarget will be checked:
- If it is allow the device will be authorized
- If it is block or reject the device will be, respectively, deauthorized or removed.

On top of that, from the CLI/DBus there is a function called applyDevicePolicy that can be used to override the decision that USBGuard took after the three steps listed above. In applyDevicePolicy there is a parameter called permanent. If it is set to False the policy override will just work as long as the device stays plugged in. Otherwise if set to True, the policy will be stored in the rules.conf file.

USBGuard limitations

USBGuard configuration can be accessed and manipulated with DBus. Unfortunately there were two major deal breaker for us:

There were no signals when a parameter were changed. In this way requiring a polling for getting the current updated configuration values.
From DBus it was possible to get and set only the InsertedDevicePolicy parameter.

The first issue was solved with this PR, now already merged in master.

The second is an issue for us because without being able to manipulate ImplicitPolicyTarget we can’t, for example, easily reach a state where we allow every new USB devices. Regarding this limitation I proposed a fix with this PR, and it is currently waiting for approval.

Work done so far

My starting point was regarding the first step where we display an entry in GNOME Control Center under the Privacy tab that let the user permanently allow or disallow new USB devices. So far I created two proof of concepts of this functionality:

The first uses a GSettings entry to store the chosen value.
The second where the displayed value always reflects the InsertedDevicePolicy from the USBGuard configuration.

For the second step the plan was to give an option to forbid new USB devices only when the lock screen was active. This can be considered a sort of a middle ground between the permanently allow and disallow. So far I did a first proof of concept where I displayed a drop down menu letting the users choose between “always”, “never” and “when lock screen is active”.

The chosen property is then propagated to the USBGuard configuration and also stored with GSettings.

What to expect in the following 1-2 weeks

Currently in the PoC that I realized I’m working exclusively with the InsertedDevicePolicy property. While this is good enough when we want to block USB devices, it is subpar when we want to deactivate the protection. The only way to be 100% sure that every new devices will be allowed is with ImplicitPolicyTarget. As soon as we will be able to control it too, I’ll adjust my implementation accordingly. In the meantime I can prepend a wildcard “allow” to the rule file to achieve the same result.

I also need to improve the USBGuard check, in order to better inform the users if something is not working as expected (e.g. too old version of USBGuard or wrong initial USBGuard configuration).

Regarding the second step I’ll create a patch for GNOME Shell that binds the USB locking logic to the lock screen process and, before acting, it checks the stored property from GNOME Control Center to decide how to behave based on the users choice. In this step also an interesting question raises: What to do with devices which have been inserted while the lock screen was on? Initially we probably keep them blocked and maybe we should show a notification about them to inform the users that they need to be re-plugged to make them work.

Thanks

I’d like to thanks Tobias Muller for guiding me in this project and the whole GNOME foundation for this awesome opportunity.

GSOC 2017 Keysign wrap up

2017-08-13T21:40:00+00:00

What was the project about

The transfer of the keys on GNOME Keysign was limited to the LAN only. This limitation can be a problem when e.g. one user does not have access to a WIFI/Ethernet connection or when the users are connected to an isolated network (like a guest WIFI or an University Intranet).

The goal was to further facilitate the OpenPGP keys signing process on GNOME Keysign. This was achieved by adding the ability to send the keys using Bluetooth and Magic Wormhole. The first allows two near PCs to communicate even if there is no LAN/WAN connectivity; The second allows the communication when two PCs are in a LAN (or isolated LAN) or located remotely.

Magic Wormhole

Magic Wormhole implementation is complete.

Now in order to use this new transfer method users just have to press the new Internet switch button. Security and secrecy of transferred keys are guaranteed by Wormhole itself thanks to its end-to-end encryption.

In addition to Wormhole, an extra page has been added to inform users about the sending result.

The code is now in a pull request here.

In addition to a code review, we are waiting until Debian updates the repository version of Magic Wormhole to the required one for keysign (version >= 0.10.2) before we can merge this branch.

Bluetooth

Bluetooth implementation is complete.

This additional transfer method is automatically active if a working Bluetooth adapter is available. The receiver, in order to use Bluetooth, will need to scan the sender’s QR code.

As a discovery mechanism the MAC address has been used, in this way the receiver can connect directly to the sender without starting a slow nearby discovery search.

For allow faster “one time” connections, pairing is not mandatory. Without pairing the transfer happens in clear text, so to guarantee that the downloaded key has not been tampered we use an HMAC.

The code is now in a pull request here.

Some code review and more beta testing are required in order to merge this pull request.

Thanks

Even if this GSoC 2017 is over I’ll definitely continue to contribute in this amazing community.

Thank you Tobias Müller for all the advice that you gave me in the past months, thank you Google for this beautiful opportunity and last but not least a big thank you to the whole GNOME community!

GSOC Keysign Bluetooth update and GUADEC 2017

2017-08-13T15:00:00+00:00

Bluetooth

With Bluetooth I ended up implementing two different ways to exchange keys because beforehand it was not clear which one of them was better.

Use BT discovery and change BT name

With this approach, after a key has been selected, the Bluetooh name will be changed to the key fingerprint. This is like how Avahi works because we create a local server with the name of the fingerprint.

In the receiving side the user needs to enter the fingerprint, then a Bluetooth discovery will start searching for the right device.

We need to start a discovery because in order to establish a Bluetooth connection we need to know the MAC address of the device to connect to.

These were in short the needed steps.

PROS:

No extra codes, we use the same key fingerprint already used with Avahi

CONS:

Need to change every time the BT name, a bit invasive approach
Relatively slow, the discovery to get the MAC address is not fast

Use the BT MAC address directly

Instead of using the key fingerprint, another way is using the Bluetooth MAC address. In this way the receiver will already knows who to connect to, and we can avoid to perform a discovery.

The problem is that now we have yet another code to display.

After some discussions I ended up with the choice of only embed the Bluetooth MAC address (the Bluetooth code) in the QR code. Doing so we can continue to display to the user always only one code. This has the downside to limit the Bluetooth use exclusively to QR code, but the reason behind it is also that the QR code is safer than manually entering the code (I’ll explain that later), so this is even an attempt to push the use of the QR.

PROS:

Faster, because we don’t need to start a discovery
Don’t need to change the BT name

CONS:

Need an extra code (BT MAC)

Considerations

Nothing is still definitive, but after some testing and discussions probably the second method is the preferred one.

Security

A transfer with Bluetooth could happen with or without pairing.

If two devices are paired the communication is encrypted, insted if they are not the communication is in plain text. Even if the encryption was a good extra feature, I avoided to add the pairing to Keysign because it required additional user interaction and also pairing a new device only for a single connection was a bit overkill. Also if afterwards the user doesn’t remember to delete the paired device it may even become a security problem.

So how can we be sure that the downloaded key has not been tampered? With an hash-based message authentication code (HMAC). In the QR code we embed a message authentication code that was also used for check the downloaded key with Avahi. In this way we can reutilize this mechanism also for Bluetooth and be reasonably safe that the received key has not been altered.

Presenting the Bluetooth option

I used the least intrusive way for the user: Bluetooth, if available, is automatically added to the exsisting transfer methods.

The advantage is that this approach requires no extra steps for the user and no extra buttons in the GUI.

Magic Wormhole

Refactoring to Inline Callbacks

Previously I implemented Magic Wormhole using the callback mechanism offered by Twisted.

After some discussions I decided to refactor the code to use the inline callbacks. The advantages are that the code flow is now more linear and easier to follow and maintain.

GUADEC 2017

–

This was my first GUADEC and I must say that it was amazing! The conference gave me the opportunity to talk to very nice people and attend beautiful talks. There were also wonderful social events! (like the 20th GNOME birthday and the walking tour for example)

I think that the talks that I liked most were:

The GNOME Way (Allan Day) and The History of GNOME (Jonathan Blandford): As a newcomer to the GNOME development, these two talks helped me to really understand the principles of the GNOME community.
Keynote: The Battle Over Our Technology (Karen Sandler): Very passionate and informative talk. Unfortunately explaining the importance of Free Software to other people is not easy.
Resurrecting dinosaurs, what can possibly go wrong (Richard Brown): I didn’t expect this kind of talk. He expressed some concerns and objections regarding Flatpak and the other application technologies. This talk made me think a lot about the current state, and what we should do to improve the situation.

I’d like to thank the GNOME Foundation for sponsoring me. This was a fantastic experience and I hope that we can met again next year in Almería.