Login   |   1.866.392.4897 |   sales@timesys.com English Japanese German French Korean Chinese (Simplified) Chinese (Traditional)



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


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.


Nathan Barrett-Morrison, Senior Embedded Systems Engineer, has 8+ years of experience in designing and debugging embedded systems. In the past, he has been a software technical lead on ultrasonic-based digital processing systems and direct thermal printing solutions. He specializes in providing customers with lower level board support packages, drivers, and numerous other services. Nathan holds a bachelor’s degree in Electrical and Computer Engineering from OSU (Ohio State University).

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.