Recent Security Enhancements in Netbsd
Total Page：16
File Type：pdf, Size：1020Kb
Recent Security Enhancements in NetBSD Elad Efrat < [email protected] > September 2006 Abstract Over the years, NetBSD obtained the position of the BSD focusing on portability. While it is true that NetBSD offers an easily portable operating system, care is also given to other areas, such as security. This paper presents the NetBSD philosophy of security, design decisions, and currently offered security features. Finally, some of the current and future research will be revealed. 1. Introduction Running on almost twenty different architectures, and easily portable to others, NetBSD gained its reputation as the most portable operating system on the planet. While that may indicate high quality code, the ever demanding networked world cares about more than just that. Over the past year, NetBSD evolved quite a bit in various areas; this paper, however, will focus on the aspect relating to security. This paper was written and structured to present a full overview of the recent security enhancements in NetBSD in an easily readable and balanced form that will satisfy new, intermediate, and experienced users. References were sprinkled across the text to provide more information to those who want the gory details, while preserving the continuity. Section 2 will present the bigger picture of security in NetBSD: how NetBSD perceives security, the design decisions of NetBSD software in general and the security infrastructure and features more specifically. Section 3 will present a detailed overview of the recent enhancements in the security infrastructure and features of NetBSD including, where relevant, details about the design, implementation, and possible future development. Section 4 will present current security-related research and development in NetBSD, and section 5 will discuss how the described enhancements work together to provide a more secure platform. Section 6 concludes the paper, and summarizes availability of discussed features. 2. The Tao of NetBSD Security We are all familiar with the mantra that security is a process, not a product . When regarding software development, specifically operating systems, it should be part of the design, from the ground up. As the descendent of an operating system over 20 years old, NetBSD carries a security model designed and implemented with different threats in mind; the Internet was smaller, more naive, and less popular. The following sections will provide background to the approach taken to enhance the security of the NetBSD operating system: the considerations, existing approaches, and case-studies. 2.1 Considerations Licensed under a Creative Commons Attribution 2.5 License 1 When approaching to enhance the security of NetBSD, two of the most important leading principles were maintaining compatibility and interoperability 1. Presenting changes that would dramatically impact the user-base was out of question, and careful planning had to be done. In addition, any change to underlying back-ends had to be well thought-out so it maintains existing semantics without enforcing them during design stage. 2.2 Security Approaches Operating system security is nothing new, and NetBSD is not the first to address the issue. In designing software – and security software in particular, it is mandatory to learn from the experience of previous work. Below are some common approaches to security and real-world case-studies. 2.2.1 Code Auditing Code auditing addresses security issues by looking for programming glitches in the source code of the program, often with the assistant of automated tools 2. Normally the work of vulnerability researchers, when done proactively by the programmers themselves, has the potential of locating and fixing bugs with security implications before anyone else finds and exploits them. While some would argue that striving to produce bug-free code is the one true way of achieving security, this view is a fallacy for two main reasons. The first is that security issues are not always the result of programming errors; while code auditing tries to ensure no software bugs will be maliciously exploited because said bugs would simply not exist, it alone ignores other important aspects, such as configuration errors and user behavior policies. The second reason is that it is not possible to write bug-free code 3. Over the past decade, the awareness to writing secure code rose significantly; automated tools evolved, allowing easy pinpointing of software bugs; open-source software is available for the review of thousands – if not millions – of people; yet, we still see new security vulnerabilities on a daily basis. Some of those, ironically, are of the exact same type that affected us ten or twenty years ago 4. 2.2.2 Exploit Mitigation The unorthodox approach of exploit mitigation addresses bugs from the opposite direction of code auditing: instead of looking for them in and removing them from software to make it more secure, it adds bugs to the exploit code to prevent it from working. While that may be over-simplified, the purpose of exploit mitigation technologies is to interfere with the inner-workings of the exploit, eliminating the – often unusual – conditions that make it work. On one hand, some would claim that exploit mitigation discourages developers from writing secure code and vendors from quickly responding to security incidents: they 1 Two other leading principles – not impacting the system performance and an easy user interface, will not be discussed in this paper. 2 Coverity, for example, offered its services to various open-source projects, including NetBSD, for free. See http://scan.coverity.com 3 http://www.cs.columbia.edu/~smb/papers/acm-predict.pdf 4 http://www.cert.org/homeusers/buffer_overflow.html Licensed under a Creative Commons Attribution 2.5 License 2 know there's a safety net guarding them, and so they pay less attention to security when writing code, or taking their time coming up with fixes for security issues. On the other hand, however, this is also where exploit mitigation technologies excel: they introduce the concept of preventing the successful exploitation of security vulnerabilities, even before a fix is available. Moreover, they prevent entire classes of bugs, and don't require constant updating. 2.2.3 Architectural Integration So far, the previous two approaches assume the cause of a security breach is a bug in the code that is being exploited. The first approach tries to eliminate such bugs, and the second one tries to make it next to impossible to successfully exploit them. However, some environments require more than just that – for example, the ability to define detailed usage policies and associate them with entities on the system became a mandatory part of many security policies. In our context, we can relate that to the Unix permissions model; simply put, due to the coarse separation between a normal user and a superuser, it cannot be used to express many security policies as detailed as may be required. That led to the research of various modern security models, of which most recognized ones are fine-grained 5 discretionary access controls (DACs) and mandatory access controls (MACs). To put things simple, DACs focus on the data owner's ability to specify who can use it and for what; MACs focus on a mandatory policy that affects everyone. These systems allow an administrator – and where applicable, the users – to specify fine-grained policies; effectively, this means that a user or a program can be made to work with the minimal amount of privileges required for their operation (which, as implied above, cannot be done with the traditional Unix security model), resulting in damage containment in case of compromise or otherwise minimized impact from security vulnerabilities. 2.2.4 Layered security To itself, layered security 6 is not a single approach. Where any of the previous three took a different route, the layered security approach suggests that maximized security can only be achieved by combining efforts on all fronts: code auditing is important, but does not come in place of useful exploit mitigation technologies; and architectural integration, of course, has little to do with any of them. Although the above may sound obvious, it is not too often when you see an operating system that puts an emphasis on all three aspects; it will usually be the case that only one of the approaches is fully practiced. Following are some short case-studies that illustrate the importance of each approach by using real-world examples. 2.2.5 Case Studies Shortly after splitting from NetBSD in 1995, OpenBSD became widely known for its unique – at the time – approach to security: proactive code auditing. Instead of 5 I emphasize fine-grained because DACs already exist on Unix; however, as noted, they are too coarse. 6 Also known as Defense in Depth . Licensed under a Creative Commons Attribution 2.5 License 3 retroactively responding to security issues, OpenBSD developers performed thorough code auditing sessions, sweeping for bugs. This act proved itself more than once, after vulnerabilities found in other operating systems were already fixed 7 in OpenBSD. This, however, did not last too long. In 2002, winds of change blew through the OpenBSD mindset: the long standing fort of code auditing fell, adopting exploit mitigation technologies to its lap 8. While the reasons behind the move were not published, some speculate that it was the release of an exploit allowing full system compromise of OpenBSD's default configuration 9 that finally proved that even a group of dedicated programmers cannot find all bugs; at least not first. Said exploit mitigation technologies made their public debut around 1996, with the appearance of the Openwall 10 project, and later evolved dramatically by the PaX11 project in 2000. Research done in both projects formed the basis of today's exploit mitigation technologies. Another commonality of the two was that they offered an implementation based on Linux – which only makes one wonder why it was OpenBSD that was the first to officially adopt these technologies.