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.