Paul Parkinson

Linux, Common Criteria, and OS Protection Profiles

In 2011, computer and network security news stories, which were previously the preserve of specialist journals and blogs, have become commonplace in the mainstream media. There are now many different types of threat, which are sometimes categorised into hacktivist, e-crime and most recently,advanced persistent threats (APT). Whilst some of these attacks have exploited zero day vulnerabilities, many of these attacks have simply taken advantage of the fact that systems have not been configured securely for their deployment environment.

To use an easy–to-understand analogy, consider a wireless router. This device will generally be shipped from the factory in the most flexible, open communication configuration, which will have many or all of the security options disabled. This will be fine if the wireless router is intended to be used as a free public Wi-Fi access point (e.g., cyber cafe), but not for a private business or home office if you want to prevent drive-by wireless hacks).  In these cases, wireless encryption such as WPA2 will need to be enabled for the router and clients, and access may even need to be restricted to specific clients via MAC addresses, etc.

For the developer wanting to create a secure product using embedded Linux, the wealth of configurable functionality and security packages can seem overwhelming. In the critical device space, the key question is, "How can one create a Linux configuration for their product which can be secure and meet the security requirements of the product's targeted international markets?"  The answer is straightforward and well defined - use standards-based approaches to both configure and prove security robustness.

For IT security, there is one globally-recognised standard, Common Criteria, that a product can be evaluated against, and this evaluation ensures that connected IT products are performed to high and consistent standards. Because Common Criteria is now recognized by 26 countries, product security evaluation using this standard eliminates the burden of duplicating security evaluations in multiple countries by providing international mutual recognition of evaluated products.

To accelerate the Common Criteria evaluation, the product can be developed according to the approved Protection Profile (PP) to ensure that it meets the accepted security requirements for that class of product. A Protection Profile is a document that defines the combination of threats, security objectives, assumptions, security functional requirements (SFRs), security assurance requirements (SARs) and rationales for a specific security target (ST). The PP is used to substantiate vendors' claims of a given family of information system products. The PP for a particular device typically specifies the Evaluation Assurance Level (EAL), a number 1 through 7, indicating the depth and rigour of the security evaluation, usually in the form of supporting documentation and testing, that a product meets the security requirements specified in the PP. In the United Kingdom, CESG supports Common Criteria evaluation and the use of PPs; in the United States, the National Institute of Standards and Technology (NIST) and the National Security Agency (NSA) have agreed to cooperate on the development of validated US government PPs.

Common Criteria testing and evaluation can be quite expensive, and adds significant risk to any programme. To help eliminate much of this risk, Wind River has taken this approach for the development of Wind River Linux Secure, a commercial-off-the-shelf (COTS) product which has been certified by NIAP under the US Common Criteria Evaluation Scheme to Evaluation Assurance Level (EAL) 4+ (EAL4 being the highest level which is mutually recognised internationally under the Common Criteria Recognition Arrangement, and "+" referring to the evaluation being augmented with the Security Assurance Requirement ALC_FLR.3, the highest level of systematic flaw remediation).

Wind River Linux Secure was evaluated against the US Government Protection Profile for General Purpose Operating Systems in a Networked Environment (US GP-OSPP). This is a new protection profile which was published by the US National Security Agency's Information Assurance Directorate in August 2010, and supersedes the earlier Role-Based Access Control Protection Profile (RBAC) which was 'sunsetted' from 1st September 2011.

With this COTS GP-OSPP foundation, we expect that evaluating Linux products under similar PPs, like the German Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik, BSI) General Purpose Operating System Protection Profile (BSI GP-OSPP) can also be undertaken. The BSI OSPP is also published on the Common Criteria portal, and defines the specific requirements for the German security market. Although there are two separate general-purpose operating system protection profiles, with some specific differences in Security Functional Requirements, there is a lot of commonality, and Wind River’s experience in evaluating a full-featured Linux distribution from kernel.org removes considerable risk from other programmes requiring Common Criteria certification using the US GP-OSPP, BSI GP-OSPP, or other evaluation scheme.

Fun with VxWorks MILS 2.1

It’s been a while since my previous blog, as I have been rather preoccupied with responding to a number of RFPs. However, I’ve managed to find some time to work on some demos for VxWorks MILS 2.1, which has been fun.

VxWorks MILS 2.1 introduced support for Wind River Linux as a Guest OS (VxWorks Guest OS and High Assurance Environment (HAE) having been supported in the earlier VxWorks MILS 2.0 release). I wanted to get some more hands-on experience of using Wind River Linux as a Guest OS (GOS) running on the VxWorks MILS 2.1 Separation Kernel (SK). So, I started with a version of the Blaster Blastee demo which had been modified by one of my colleagues in Engineering to use a Linux GOS partition for the Blaster. (Blaster Blastee is a well-known Wind River demo which provides a nice flexible framework for blasting TCP or UDP packets between nodes, testing network connectivity and performance).

 I thought it would be an interesting exercise to extend the demo to also use Linux in a second partition as the Blastee (receiver), to demonstrate the scalability and determinism of the MILS SK with multiple Linux virtual boards (VB).

This proved to be quite easy to configure, as I was able to use the same Linux kernel image as the Blaster virtual board, but with different boot parameters (as this virtual board was using a separate dedicated Gigabit Ethernet device on my target board, with its own IP address), and I just invoked the Blastee executable which had been built into the Linux GOS filesystem. Once I had added a timeslot allocation for the Blastee VB into the MILS system schedule, I was able to build and run the system and send packets between the two partitions via external Gigabit Ethernet interfaces.

(Side note: Alternatively, I could have sent packets directly between the two partitions either by using Secure IPC ports via the MILS SK according to pre-defined security policy, or even via an IP tunnel over SIPC, but I used the external Ethernet interfaces, as I wanted to extend the demo further).

The next step was to configure this Linux GOS-based system to send and receive packets via the two Ethernet ports to corresponding VxWorks GOS-based Blaster and Blastee virtual boards on a second board. This configuration can be used to simulate a Public Network and a Secure Network connection between two nodes (see diagram above). The original MILS Blaster Blastee demo also includes a trusted Security Audit partition, running in a High Assurance Environment, which monitors the audit log for each partition, and also a Rogue partition which attempts to illegally access the Secure Network interface to intercept traffic (which is of course prevented by the MILS SK). When this demo is running freely, the link lights on my Gigabit switch flicker away furiously, and the VxWorks MILS partitions report output via the multiplexed serial I/O output to a host console.

To really see inside the system, and to step through the interactions of the sender and receiver (Linux Blaster to VxWorks Blastee over the Secure Network, and VxWorks Blaster to Linux Blastee on the Public Network), I used Wind River Workbench to debug all four connections concurrently, using Linux user-mode agents in each of the Linux VBs, and On-Chip Debugging (OCD) via JTAG to debug the VxWorks Blaster and Blastee. In this way, I could step through the sending and receiving of packets in both directions over the two networks (rather than having to rely on printf(), which would have been difficult to correlate across multiple partitions). The screen shot shows the point at which I am stepping through send and receive (the size of the screen shot is constrained by my 19” monitor).

So, this demo shows how the High Assurance Environment, VxWorks GOS and Linux GOS can all run on top of the MILS Separation Kernel and still provide good network performance despite being in a time-partitioned environment.

National Cybersecurity Strategy

On Monday, the UK government published its new national security strategy (PDF). This outlines the current and emerging security threats to the UK national interests, ranked by priority based on likelihood and impact. What caught my attention was the fact that the Tier 1 (highest priority) threats include:  

'Hostile attacks on UK cyber space by other states and large scale cyber crime'

Until fairly recently, the threat of cyberwarfare has mainly been discussed in defence and security journals (see 'Evaluating Cyber Security', Digital Battlespace, Aug 2009), but there has been a growing focus on this in the mainstream media (although whether this is due to an increasing threat or an increasing media appetite is subjective).

However, recent events have shown that it is now possible for cyberwarfare attacks to be directed at specific targets, rather than being undirected and indiscriminate. This has been illustrated by the Stuxnet worm incident, which has been alleged to be a a state directed cyber attack ('The Stuxnet worm heralds new era of global cyberwar', The Guardian).

Cyberwarfare provides the the potential to bypass a nation's conventional forces and strike at specific targets including critical national infrastructure whilst remaining invisible and providing the prospect of plausible deniability. The types of cyberwarfare threats were discussed by Iain Lobban, Director of the UK's GCHQ security agency in an unusual public speech.

The UK government's response will be to invest £500m in cyber defences to bolster the UK's critical national infrastructure. At present, few details have emerged on how this will be implemented or how the security of systems will be evaluated. However, if you're using a system which has undergone a security evaluation under conditions which assume that it's connected to a benign network, then you might as well shutdown and pull out your network card now. Instead, we should be basing our critical national infrastructure systems on platforms which are designed to achieve the highest levels of assurance with real-world protection profiles and be resilient against network-based attacks.

http://www.direct.gov.uk/prod_consum_dg/groups/dg_digitalassets/@dg/@en/documents/digitalasset/dg_191639.pdf?CID=PDF&PLA=furl&CRE=nationalsecuritystrategy

VxWorks MILS 2.1 Platform hands-on

Last week, I visited Wind River headquarters in Alameda, California, to learn about VxWorks MILS Platform 2.1 and to get hands-on experience with the release.

I had been looking forward to the trip, as the 2.1 release adds some significant new capabilities: Wind River Linux as a guest operating system and the new High Assurance Network Stack (see Bill Graham's recent blog for a more detailed overview).

So, the VxWorks MILS separation kernel (SK) can now host Wind River Linux, VxWorks and a High Assurance Environment as guest operating systems in a virtualised environment (as shown below).

To me this is a very significant development, as it extends the depth and breadth of applications which can be run in on top of VxWorks MILS. This enables existing applications to he hosted securely in a high robustness system, but also enables new systems to be developed using the most appropriate technologies for a given component.

Of course, learning the theory is great, but it is not as much fun as hands-on experience, so I was glad to have the opportunity to run some Wind River Linux demo applications on top of VxWorks MILS and run and debug them using Wind River Workbench while I was in Alameda.

The screenshot below shows Workbench debugging a multi-threaded Linux application running on top of VxWorks MILS 2.1 on my PowerPC 8548-based demo board. There's a thread-specific breakpoint on a line of shared code, which can be used to halt one thread while the other thread(s) run free. 

The next step will be to incorporate these new capabilities into some MILS demos. Stay tuned.

South African A&D Seminars

Tomorrow, I will be traveling to South Africa to present at the Wind River Aerospace & Defence Seminars which will be held in Pretoria and Cape Town next week. 

I'm really looking forward to the events, as we will be covering some interesting topics including the latest trends in Aerospace & Defence, including Safety and Security. This will also be the my first opportunity to present some new Wind River A&D customer case studies, which I hope the audiences will find interesting and informative. In the afternoons, we'll be providing some technical deep-dive sessions on Multicore, Virtualization and Hypervisor technologies, VxWorks 6.6 safety certification, and Wind River Linux. So it's a pretty packed agenda.

I'm also looking forward to seeing the scenery again which is stunning, particularly around Cape Town and Stellenbosch. Thunder City, on the outskirts of Cape Town, has three operational English Electric Lightnings, which is my all-time favourite military fast jet. It would provide the ideal way to see Table Mountain and The Cape in real style, but unfortunately, that's not part of the seminar programme. (For some interesting facts and anecdotes on the Lightning, the Wikipeda entry is well worth reading!).

RTLinux acquisition from FSMLabs

I was really pleased to see the news about Wind River's acquisition of RTLinux hard real-time Linux (ZDnet) from FSMLabs.

Linux is already starting to be used in certain types of Aerospace & Defence applications due to its maturity (which I discussed in the previous blogs: 'Linux in Aerospace & Defence' and 'Linux fit for Defence'), but these are mainly non real-time classes of applications where Linux has provided a good technical fit to the requirements. However, RTLinux technology extends the reach of Linux into real-time, because it achieves hard real-time performance where as some other real-time Linux implementations have only achieved soft real-time and have also forked the Linux kernel with proprietary extensions which could be a maintenance nightmare on A&D programmes with long in-service lifetimes.

You may be thinking that Linux as provides high performance on modern microprocessors, so does the distinction between soft and hard real-time really matter? In my view, it matters a great deal. 

• A real-time system is one which needs to complete a number of operations correctly by a specific deadline.
  
• In a hard real-time system, completion of the operations after the deadline is unacceptable and may even result in system failure.
• In a soft real-time system, deadline misses can be tolerated with degraded system performance.

Back in the days when I wrote host platform device drivers and libraries for high-performance multiprocessor DSP VMEbus (VITA) systems, I needed to develop stress tests to assess how the device drivers would perform under the severe loads which might be encountered in a deployed application. One test involved sending VME interrupts from a DSP (wikipedia) slave board to a host platform as fast as possible.  Of course, the DSP was able to generate interrupts at a very high sustained rate, and I was able to accurately measure with a VMEbus analyser the interrupt response times of the host platform and its operating system (which was either a multi-user OS or an RTOS). 

What was interesting when comparing the performance of the various operating systems, was not just the typical interrupt response times, but the variation between best case, worst case and average response times for each of the operating systems, especially in relation to increasing system load. This revealed that although some of the soft real-time platforms could achieve fairly respectable interrupt response times most of the time (especially under fairly light load), under severe load, the interrupt response times could vary dramatically. The hard real-time platforms (VxWorks in particular)produced much less variation.

The outcome was that the suitability of a particular host platform to the performance requirements of a specific application wasn't determined by its best-case response time, but on its worst-case response time. For me, this lesson has a direct bearing on the suitability of Linux for hard real-time applications; as RTLinux's hard real-time performance not only provides faster response, but also much better determinism and predictability, this will enable the adoption of Linux in a new class of applications. In A&D, I expect that Linux will now be able support certain types of radar and communications applications, etc.; but of course there will always be applications with such as EW (electronic warfare) systems and other sensors which even RTLinux will not address but they will instead will exploit the extreme hard real-time performance of VxWorks for a tactical advantage (for example, sub 2 microsecond interrupt response time on a 1GHz PowerPC), but these are at the two ends of the hard real-time spectrum.

So, now it's Linux - fit for hard real-time defence.

Linux fit for Defense

In an earlier blog, I commented on the potential use of Linux in Aerospace & Defense, but I didn't provide any background information to support my assertion that people seem to either love or hate Linux, and that often their views are formed from emotive arguments and prejudice rather than rational fact-based discussions.

Last week, Paul Tingey discussed some interesting examples of polarised views in different countries in a recent blog Open Source: Do you love or hate it? So, I thought I should comment on some of the views which have been expressed in relation to the use of Linux in defence.

In the article 'No Defense for Linux' (Design News), Green Hills Software CEO, Dan O'Dowd, shared his views into what he believes are potential security issues relating to the use of Linux in defence systems. The article is both interesting and thought provoking, and Mr. O'Dowd raises some important questions which do need to be considered.

A number of other bloggers have already commented on this article from a number of angles, the one's which I found the most interesting were Victor Yodaiken: Green Hills, foreigners and the gummi bear threat'; Dana Blankenhorn: 'Is Linux a Danger to National Security?', and  Perry E. Metzger: 'News Flash: Proprietary OS vendor dislikes Linux!'). However, I want to follow-up on two of the arguments in the article in particular, as they do not appear to stand up to close scrutiny:

1. Open Source peer review
   Mr O'Dowd asserted that "many eyes" are no defence against subversive or malicious code which could be used to undermine system security.  However, this argument is inconsistent with the accepted best practice for the definition of network security protocols. It has been well documented that security protocols, such as Wireless Equivalent Privacy (WEP), which was designed in isolation without peer review by security experts, was fundamentally flawed. The flaws are documented in Security of the WEP algorithm (Berkeley), and the lack of peer review is highlighted by Jon Edney and William Arbaugh in their book "Real 802.11 Security". This should be contrasted with the approach taken to develop 802.11 wireless security which uses the Advanced Encryption Standard (AES, wikipedia).
   
2. Vulnerabilities in Binary Code
   Mr. O'Dowd also asserted that 'source code inspection will never detect vulnerabilities that are only manifest in a system’s executable binary code', which is of course a valid statement. However, the example which he used to illustrate this doesn't actually support this argument. He cited the story of Ken Thompson, one of the original designers of the UNIX operating system, who installed a backdoor (a.k.a. Trojan Horse - wikipedia). Mr. O'Dowd said that Thompson "installed a back door in the binary code of Unix". This statement seem to be slightly ambiguous to me, and I wasn't sure if it meant that the backdoor was installed into the UNIX kernel, so I checked the original article by Ken Thompson 'Reflections on Trust ' (ACM) and found that states explicitly that the Trojan code was actually contained within the UNIX C compiler:
   

   "The actual bug I planted in the compiler would match code in the UNIX "login" command. The replacement code would miscompile the login command so that it would accept either the intended encrypted password or a particular known password. Thus if this code were installed in binary and the binary were used to compile the login command, I could log into that system as any user."

   So, the comparison between Linux and UNIX  does not appear to be valid in this instance because the GNU C compiler used in Linux is Open Source whereas the UNIX C compiler was not. So the Linux GNU C compiler can undergo source code inspection in the same way as the Linux kernel, so there will be no binary code that has not undergone source code review. Ken Thompson also described a very devious approach to install a backdoor into the UNIX C compiler, which would re-insert itself without when the compiler was recompiled. However, Ken Thompson acknowledged in his article that:
   

   "Such blatant code would not go undetected for long. Even the most casual perusal of the source of the C compiler would raise suspicions."

   A backdoor could be inserted into the GNU C compiler using the same technique, but this could be detected by disassembly of the compiler.

So, it would seem that at least some of the arguments against the use of Linux in defence systems do not seem to have a firm foundation based on facts. Don't get me wrong, I'm not saying that Linux is suitable for all types of defence application, but as I discussed previously, I do think we need to have an open mind.

Linux in Aerospace and Defense

In a recent blog entry, John Bruggeman considered the role of Linux in Automotive applications. He discussed the blurring of the distinction between car infotainment systems and driver assist systems. This got me thinking about the adoption of Linux in the Aerospace & Defence market, in particular the potential use of Linux and safety-critical avionics and military vehicles, which I hadn't really thought much about before.

It seems to me that people's attitudes towards Linux can be rather polarised at times - a bit like Marmite (wikipedia), people either love it or hate it. Over the years I've written applications and device drivers for a range of enterprise UNIX platforms and real-time operating systems, and whilst I've experienced for myself the relative merits of each of theses OSs for particular types of application, I've never felt threatened by the advent of Linux, I've just been curious as to its potential. So, I want to form a view on Linux in A&D from rational fact-based discussions not from emotive arguments and prejudice.

I've noticed the increasing adoption of Linux in A&D for mission-critical enterprise and embedded applications in recent times, for example RSTA-MEP and the Linux Crewstation (LinuxJournal) and Boeing P-8A Multi-Mission Maritime Aircraft (Linux Sys-Con) respectively. I suspect that this may be related to the maturing of the Linux kernel and the Carrier Grade Linux specification - these topics were recently discussed in Paul Tingey's blog Is Carrier Grade Linux Winning New Friends?, and Paul Anderson's blog Raising The Bar.

In the case of avionics there are different classes of systems: safety-critical systems, such as the head-down primary guidance flight displays (which use safety-certifiable RTOS such as VxWorks/Cert and VxWorks 653 and others); and non-critical systems (a.k.a. mission critical systems), which include secondary guidance systems such as digital map display (such as TARDIS) and Head-Up Displays (HUD), which although they do not have an RTCA DO-178B safety certification requirement today, this could possibly be mandated in the future.

In the case of military vehicles: there are programmes developing vehicles with electric motor propulsion under software control, such as SEP (Army Technology). As well as charging across battlefields, I imagine that such vehicles will be driven on public roads, which is quite similar to the civil automotive scenarios described in John's blog, and it's reasonable to expect that they would require safety certification under ISO/IEC-61508.

So, for these classes of A&D applications, what are the options for safety-certification using Linux?

There are Linux distributions which use a pristine source tree, so could this conceivably be used as a foundation for traceability and requirements-based testing for DO-178B safety certification?

What about the safety-certification cost (assuming DO-178B Level B-D), could this become economically viable if a trusted Linux profile with a reduced source lines of code (SLOC) count were defined?

If not, another alternative might be to consider a virtualization approach, perhaps using a MILS (Multiple Independent Levels of Security) architecture?