Security for embedded systems is a serious issue, though 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 these issues.

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 Northern 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 always a popular target for attackers this easy mechanism will decrease the risk for those kinds of brute force attacks.

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.

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.

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.