White Papers

SELinux and Least Privilege

After you have ensured that the physical flash is secure and running clean, signed Dell EMC firmware images, the next

step is to protect the system from online attacks that would allow an attacker to gain access to a running system through

some software vulnerability. We have done this through a combination of two techniques that we have integrated into

our development process. First, we have adopted SELinux for all of the management controllers in the MX7000: the

Management Module as well as the IDRACs. The 1.0 version of MX7000 firmware ships with SELinux fully enabled and

set to the highest level of enforcement out of the box, without any configuration requirements for customers to worry

about. The second major runtime security initiative that we have delivered is “least privilege”. This security concept

enforces each process to run with an individually unique, non-administrative Unix user account. The combination of

these two security techniques helps to mitigate any vulnerabilities that might be found: what would formerly have been a

major security hole can sometimes be mitigated down to a minor inconvenience.

This combination of SELinux and “least privilege” protects the sensitive areas of the MX7000 iDRAC and Management

Modules. Only the processes associated with establishing machine to machine trust have access to the private key

information on the device and access to these processes limited. With defined separation of tasks and access between

the difference processes, an attacker of the MX7000 would find their ability to modify or control a system extremely

limited, and accessing a remote system unlikely.

Machine to Machine Trust

So far, we’ve been building up a single system piece-by-piece in a secure manner, first by encrypting and verifying the

boot process, next by ensuring that the running firmware image is protected. Next, we need to think about how we

ensure that each component in the chassis can trust the other components and communicate with them in a secure

manner.

As noted previously, each Management Module and iDRAC have a unique Identity certificate, signed by a Dell

Certificate Authority. These certificates are a key part of the trust establishment between the various iDRAC and

Management Modules inside the MX7000. Each system on startup will verify the installed certificates against the Dell

EMC Root CA to assure they are valid. Certificates that are corrupted or invalid will be unable to establish machine to

machine trust with other devices in the chassis.

Once assembled and powered on the MX7000 Management Modules and iDRACs will automatically start the discovery

and machine to machine trust establishment process. All network communication inside the MX7000 is done over

private IPv6 VLANs. The addresses in these VLAN’s are stateless and based on the router advertisement from the

Enclosure controller. To locate other devices over the 2^128 IPv6 address space, individual devices use mDNS

announcements to broadcast their presence. As the iDRAC and Management Modules discover each other they begin

the process of establishing machine to machine trust.

A Management Module or iDRAC wishing to access resources on a discovered iDRAC or Management Module will

need to prove it is an authentic Dell device to gain access. A ECIES (Elliptic Curve Integrated Encryption Scheme) using

a ECDH (Elliptic Curve Diffie-Hellman) key exchange is used to pass the public portion of a “clients” certificate to the

discovered “server”. The server will validate the certificate chain of the public certificate against the Dell root CA. If

valid, the server will use the public key present in the certificate to form the shared symmetric key. The final piece of the

puzzle is giving the server a way to validate that the client actually has access to the private key for the unique identity

certificate. To do this, the server uses a technique called “proof-of-possession” that is specified in RFC 7800. The proof-

of-possession verification assures the server that the client has both public and private portions of a valid Dell Identity

certificate. Having fully vetted the client, the server will provide the client with a temporary JWT (Java Web Token) that

the server has signed and the client can use to access the resources of the server.