This is a follow-up from our Accessing the U-Boot environment from a C program blog post.

🌳Need to protect the environment

When you’re trying to harden an embedded Linux device to make it more resistant to attacks, one key part to secure is the bootloader, because that’s the part that boots the operating system. Even you implement a secure boot chain, if an attacker manages to interrupt the boot process and get access to the bootloader shell, this attacker would be able to load and run her/his own payload on the device.

Need to modify the U-Boot environment from Linux

A/B update and recovery workflow implemented for a Root Commit customer

There are multiple reasons for wanting to modify U-Boot variables from Linux, one of them being to implement A/B update mechanisms. Typically, after you’ve flashed a device with a new version, you’ll set the upgrade_available U-Boot variable to 1, reboot, and let U-Boot try to boot the new version.

This is another blog post about securing your Yocto built systems:

• Securing Yocto Built Systems overview presentation slides

• Yocto Security: Production and Development Images

• Yocto security: Kernel Hardening ⬅️

Introduction

The Linux kernel is the cornerstone and stronghold of a Linux based system. Unlike user-space applications which run with limited privileges, if it’s compromised, there is almost no limit to what an attacker can do.

While nothing is unbreakable, there are two types of settings you can change to make your kernel harder to compromise:

When you are on the go, have you thought about connecting your GNU/Linux PC to the Internet through a USB connection to your phone?

• Using open networks is definitely not recommended. Your connection is not encrypted and others could intercept it. If you have no other choice, connecting to the Internet through a Virtual Private Network (VPN) is strongly recommended.

• Even using an untrusted WiFi network protected by a password (like in a hotel or in a commercial building) is not fully secure. If the password is shared, other guests could intercept your connection and try to attack your PC. Here, a VPN is recommended too.

This blog post is part of a series about securing your Yocto built systems:

• Securing Yocto Built Systems overview presentation slides

• Yocto Security: Production and Development Images ⬅️

• Yocto security: Kernel Hardening

What to avoid

So, you use Yocto to build an image for your embedded device. You tweak the image and distribution settings to get the features you need, and other developers use the SDK built by Yocto to create and build the User Interface and other applications.

Last week, I gave a “Making Yocto Built Images More Secure” presentation at the Embedded Linux Conference in Amsterdam.

The main goal was to share the research I’ve done so far for a customer project, and gather feedback from the audience.

Have you checked the passwords.google.com page? If you have a Google account, it’s the passwords that you’ve supposedly allowed Google to remember for you.

In my case, I have a very limited list, and it’s so old that I don’t even remember letting Google remember them. I most probably accepted this on an Android phone, hoping that the system would store them in a secure way.

However, these are still valid passwords that are poorly protected:

Here’s a presentation I prepared for high school students in my area, but which actually targets any computer and smartphone user. Here are the main topics:

• Get familiar with the biggest threats. Also learn about less frequent but also more advanced threats.

• Protect your personal information and that of your contacts.

• Protect your computer, your smartphone and the data they contain.

• Improve your daily practice and the durability of your data.

The presentation is available in English and in French.