Few embedded designs are isolated these days. Still, most users and quite a few developers only think of names and passwords when it comes to security. Yet there’s much more, and it really needs to be incorporated throughout the design process. It also means you need to grok security.
I thought I did until I had to complete a more complex installation of multiple Security Enhanced Linux (SELinux) systems running as virtual machines (VMs) on a Xen server. I was using CENTOS, a free version of Red Hat Linux. SELinux is enabled by default, and sticking with the standard packages resulted in a secure system that worked just fine until I started moving away from the conventional configurations.
I had to learn security debugging techniques to figure out what I was doing wrong. Searching the Web helped. Fixing the problem then was trivial. In my case, I was lucky enough to have someone else do the base design.
SO WHAT IS MLS? SELinux implements the Flask security architecture, which supports a number of access control policies including type enforcement, role-based access control, and multilevel security (MLS). MLS permits higher-level access to less sensitive information.
SELinux removes one of the major problems with Linux, the root super user account. With SELinux and similar systems, user accounts should only get the access they need. This means developers have to understand what access is needed and what isn’t. Too little access and things don’t work, as in my case. Too much and an undesired breach of security can result.
My problem was an issue of role-based access control and policies that were in place with respect to the storage and VM images. SELinux tracks not only the files and directories involved but also the hard-disk volumes containing them. By default, Xen images cannot be stored on newly added hard disks or virtual volumes. I was using the Linux Logical Volume Manager (LVM) as well. Set the proper security contexts and everything works and is bundled up tight.
So is SELinux the ultimate? Of course not. Red Hat’s Enterprise Linux with SELinux meets Common Criteria Evaluation Assurance Level (EAL) 4. The highest rating is EAL 7, and you need to move to operating systems like Green Hills’ Integrity or Lynuxworks’ LynxOS. Meeting these security levels is a combination of validation and features. Validation is time-consuming and costly, though, which is why few platforms receive EAL 7 certification.
SEPARATION KERNELS The MILS (multiple independent levels of security) architecture addresses domain separation. It’s simpler than MLS and often sufficient for many applications.
Multiple single-level (MSL) separation kernels like Integrity with Padded Cell support and Lynuxworks’ LynxSecure take advantage of VM hardware that is becoming more common. Standard on most 64-bit architectures, it allows operating systems or standalone applications to run on a single machine so one VM can’t corrupt another.
The main difference between products like Integrity and LynxSecure and other VM products like Microsoft’s Hyper-V, VMware, and Xen is the size and complexity of the hypervisor that controls the VM hardware and system. In this case, smaller is better and also easier to verify, which is why LynxSecure and Integrity are utilized in highly secure applications.
MLS systems like SELinux are often found on servers and workstations and in higher-end embedded systems, but they will be found in lighter-weight platforms as well—even cell phones. MontaVista’s Mobilinux implements uSELinux basics, providing security and foregoing the higher-end facilities that are invaluable on servers but not on embedded platforms.
Reprints
