Security for embedded systems is a serious issue, albeit often overlooked. This chapter gives an overview of common security risks that might occur during the deployment and lifespan of the product. We also give hints and tips on the implementation of some chosen security mechanisms. Since we are not able to cover every possible risks in the manual, users are strongly recommended to read on further topics regarding this issues.
For the following list of security risks, no claim of completeness can be made. There may arise other risks or - on the opposite - limitations in the design of your application by following the instructions provided in this chapter.
Services
SECO Northern Europe devices are initially shipped with a “developer friendly” state. That means, all services are available and already activated. This provides a helpful state on which customers can easily deploy further application. However, leaving those services unchecked can lead to potential security risks. Once the customers have finalized their deployment on the devices, we recommend a review of the services in-used and to disable all those that are not required for the applications. See chapter [Services] on how to disable.
Independent of the device’s application, following special cares need to be taken:
SSH
An SSH services is enabled by default on SECO Northern Europe devices with Yocto. In addition to the password and user suggestions from [User permissions concept], there are more hints on securing the ssh service in the chapter [SSH service]. It is possible to restrict users allowed using this service, lock SFTP access to a subfolder only and create custom crypto keys.
User permissions concept
Linux is designed as a multi-user system and provides a mechanism known as file permissions. Each file has an owner, a group and flags that grant write, read and/or execute permissions to the owner, the group or anybody. Additionally there is a super user, called root, who has access to all files. More information on this concept can be found here.
Customers should follow the principle of minimal privilege for user rights on the devices. Please note that SECO Northern Europe tools are usually assigned with access rights for all users since it is more developer friendly.
Root password
Since SECO Norther Europe is an OEM manufacturer and we are delivering serial-produced devices to several customers, a default root password would lead to a form of pseudo security. Moreover a default password for all devices is highly vulnerable. For this purpose our devices usually have no root password set. It is essential that a password will be set by customers before the devices are deployed. This is the minimum security measure to be done.
What does it mean if no root password is set? Without root password, anyone connect to the device will have full system control since root user usually have all permissions on the system.
Blocking root access. Linux offers the opportunity to disable the root-login for specific services like ssh, or the serial console. Since the root login is is always a popular target for attackers this easy mechanism will decrease the risk for those kinds of brute force attacks.
Ensure that another user account with the possibility to gain super user (su) rights is created before the root access is disabled. Otherwise, you might completely lose access to the device.
Non-root users
Normally a non-root user should be used for "everyday tasks" on the system.
superuser privileges for non-root users
sudo allows non-root users to have access to single commands with root user privileges. If login for root user is disabled, this can be used by non-root user to do system tasks. To enable usages of this feature, the group sudo should be enabled in the sudoer file and the user needs to be added to this group.
Flash-N-Go System
Newer SECO Northern Europe devices are equipped with an Flash-N-Go System as backup OS. Within Flash-N-Go the user has full control of the device’s configuration and the partitions on the flash disk respectively eMMC without a password or further authentication
As described in [Deploying the Linux system to the target] booting into Flash-N-Go System can be triggered by pressing the bootmode switch or with the bootselect tool from the yocto OS.
The bootselect tool can only change the bootmode when called with root privileges, so following password and user suggestions from [User permissions concept] should solve this issue.
The bootmode switch should be secured with restricting physical access by the mechanical construction.
If this is impossible, it is recommended to disable the backup OS.
This change disables the access to the backup OS Flash-N-Go System completely. If the normal OS becomes inaccessible for some reason, there is no way for a customer to fix the device.
Updating the system normally without the backup OS Flash-N-Go System is impossible. Though it is possible to revert the change and re-enable Flash-N-Go System from the normal OS, if it is functional.
Networking
Firewall - netfilter/iptables
By default, all network communication is allowed. However, Linux can be configured to block certain IP packets depending on its header (e.g. by port or by protocol) using iptables, which is basically a firewall. As this mechanism is very powerful and complex, it is not documented here in detail. Please take a look at the following link for a basic introduction.
As a first start we show some basic usecases here.
If you call these commands from a network login, your connection will/could break. Without physical access to the serial or USB console, you won’t be able to access the device anymore.
Using secure network protocols
Newer and more secure network protocols, e.g. HTTPS, FTPS and SSH, are strongly recommended over their outdated counterparts.
Further mechanisms regarding the security for network connected Linux systems are described here.
Restrict physical access
Each physical interface like USB, SD-Card or Ethernet socket can serve as possible entrance gates for attackers. Unessential ports should be physically disabled or restricted from easy outside access. This reduces the likelihood that an attacker can connect to the system and therefore lower the risk of a potential security issue.
Application security
Application security is seldom a high priority for embedded devices. But it is, of course, essential to take account of identifying risks in embedded applications. Since application development is a very complex subject and it is out of scope for SECO Northern Europe, we will refer to secondary lecture at this point.