Discretionary Access Control hardening can further improve your embedded system’s security by limiting userspace access to proprietary intellectual property, exploitable binaries, and privileged information. The example permissions shown here are defaults produced during a demonstration Yocto build.
In Linux, a file has the following relevant parameters (when listing a file with the “ls” command):
| File Info | Owner | Group Users | Other Users | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Name | Owner | Group | Read | Write | Execute | Read | Write | Execute | Read | Write | Execute |
| /bin/tar.tar | root | root | r | w | x | r | – | x | r | – | x |
Where:
| r | Readable |
| w | Writable |
| x | Executable |
| – | No permissions |
| s | Executable + Set User ID or Group ID |
To fully secure your system and limit your vulnerable attack surface, these permissions should be restricted as much as possible.
User Accounts
You’ll want to ensure that your applications are well isolated from one another through the use of strict user accounting. Many embedded systems run everything under the root account. If security is a concern, this is not acceptable. If an application running as root becomes subject to an exploit (zero-day or otherwise), an attacker will be able to gain root access to your system. Compartmentalizing and restricting access between applications is critical.
This is why applications like NTPD, Apache2, Avahi, and DHCPD change their user after being initially launched as root. If someone were to successfully perform an injection-style attack on one of these network-based applications, root privileges are not exposed and, ideally, only the attacked application’s settings and files are modifiable.
Proprietary applications and intellectual property should also be executed under a separate, non-root, account. Alternatively, you can also promptly drop root permissions and change users after launching if desired. These applications are usually not as heavily tested for security vulnerabilities, as they’re not open source. This makes keeping them isolated from root access especially important, as they may be easier to attack.
SUID/SGID Protections
Also check for “Set User ID” and “Set Group ID” bits in your file system permissions. These have been commonly exploited in the past and can lead to unexpected root privilege escalation. Consider this CVE that is related to exploiting the commonly used Shadow utility (groupadd, groupdel, groupmod, useradd, userdel, and usermod).
- In an embedded system, you may not need to add/remove/modify users after building the BSP. If so, consider deleting these tools from your system altogether.
When using modern versions of Busybox, the binary has been split in to two pieces. One with SUID permissions and one without.
In this demonstration build, the SUID binary is used (via symbolic links) for the following:
/usr/bin/passwd -> /bin/busybox.suid /usr/bin/traceroute -> /bin/busybox.suid /usr/bin/vlock -> /bin/busybox.suid /bin/ping -> /bin/busybox.suid /bin/ping6 -> /bin/busybox.suid /bin/login -> /bin/busybox.suid /bin/su -> /bin/busybox.suid
You may not need some (or any) of these features in your field-ready systems. They should be disabled via the Busybox configuration whenever possible.
| File Info | Owner | Group Users | Other Users | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Name | Owner | Group | Read | Write | Execute | Read | Write | Execute | Read | Write | Execute |
| /bin/busybox.suid | root | root | r | w | s | r | – | x | r | – | x |
| /bin/busybox.nosuid | root | root | r | w | x | r | – | x | r | – | x |
Read Permissions
Restricting group and other users from read access on any system files which may expose vulnerable information is another way to improve security. By default, Yocto sets most files to be user and group readable. This is largely unnecessary, as not all users should need read access on configuration files and applications which they do not have execution privileges for.
For example, consider fw_env.config. This file is used to control the address and size of the bootloader›s environment information (from within Linux userspace). While removing the read permissions on it may not prevent a motivated attacker from finding the addresses manually, why make it easier for them? There’s most likely no reason every user in your system needs read access to this file.
root@board:~# cat /etc/fw_env.config # [Device] [Offset] [Size] [Sector Size] [Sector Count] /dev/mmcblk1 0xC0000 0x2000 0x2000 1
| File Info | Owner | Group Users | Other Users | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Name | Owner | Group | Read | Write | Execute | Read | Write | Execute | Read | Write | Execute |
| /etc/fw_env.config | root | root | r | w | – | r | – | – | r | – | – |
Properly adjusting read permissions may also be important for clone and binary analysis protections. Consider that a malicious entity is targeting your system in an attempt to copy out your proprietary binary files. The ARMv7 and ARMv8 architectures are so common now, it may be exceptionally easy to transplant these files on to a replica board. They may also disassemble said binary and attempt to find security flaws in it. If you can prevent read access to the application, it becomes more difficult for an attacker to obtain a binary copy.
Contemplate a system with three accounts named: root, user, and proprietary_app. Your system initialization manager will start up as root and launch your application under the separate proprietary_app account (or the application itself will quickly do so). At this point, if you have the permissions adjusted accordingly:
- The application does not expose root privileges if an attacker finds an exploit on it, as it’s running under a separate account.
- The application can only be read by two accounts (root and proprietary_app). If these two accounts are then passwordless, obtaining a binary dump is more difficult (bruteforce attacks via serial/SSH are not possible). It would also protect against offline cracking of the /etc/shadow file, although if an attacker is able to obtain this then they’ve already escalated to root privileges and that most likely becomes a moot point.
| File Info | Owner | Group Users | Other Users | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Name | Owner | Group | Read | Write | Execute | Read | Write | Execute | Read | Write | Execute |
| /usr/bin/some_proprietary_app | proprietary_app | proprietary_app | r | w | x | – | – | – | – | – | – |
Execution Permissions
This is another avenue through which you can help protect your system. When looking at the executable binaries in your system, you may find group and user executable bits which do not need to be set. Considering U-Boot’s environment tools (from Linux userspace) again, the tool binaries are also unnecessarily executable by group and other users. This may give an attacker an easy method of tampering with the bootloader (if it has not been adequately hardened).
| File Info | Owner | Group Users | Other Users | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Name | Owner | Group | Read | Write | Execute | Read | Write | Execute | Read | Write | Execute |
| ./sbin/fw_printenv | root | root | r | w | x | r | – | x | r | – | x |
| ./sbin/fw_setenv | root | root | r | w | x | r | – | x | r | – | x |
Write Permissions
During the demonstration build with Yocto, only the owner appears to be given write access to files. There does not appear to be any improvement necessary here. Your build system’s results may vary. If you find a file with inappropriate write permissions then you will want to fix it.
Timesys DAC Reporting Tool
Timesys has a discretionary access control review tool which will generate a comma-separated value (CSV) file during your Yocto build process. This file contains a list of all your binaries, user and group ownerships, and their various read/write/execute permissions. This enables you to more quickly scan your file system for potential conflicts. The tool is part of Timesys VigiShield offering. To view a sample report generated by the tool, click here.
About Timesys
Timesys has extensive experience with embedded system development and lifecycle management. Timesys has been instrumental in working with global leader semiconductor manufacturers with smart, quick and quality solutions for highly complex systems with accelerated product innovation and multiple product variants.
