2006-10-03
Article continued from Page 7
5. Component Interaction
So far the focus was on introducing the new infrastructure and features in NetBSD, as well as some on-going development. However, no emphasis was put on the interaction between the various components, and how they all cooperate and contribute to NetBSD's layered security model.Throughout this section we'll examine the role of each feature in the layered security model.
5.1 Attack Vectors
Attacks can be conducted on various parts of the system, most commonly exploiting bugs in services (remote and local), misconfigurations, general program misuse, and user actions monitoring. Furthermore, post-compromise attacks include implanting trojan horses, backdoors, and rootkits.Being a multipurpose operating system, NetBSD's security was designed to also be flexible and without a single point of failure: acknowledging different needs in different environments, the various security features are fully customizable, and the system is configured with sane defaults to ease administration.
5.2 Layer One: Exploit Mitigation and Privacy
In attempt to render an exploitation attempt itself as useless, the exploit mitigation features in NetBSD provide the first layer of security. The curtain hooks help protect the privacy of users in a multi-user environment, minimizing the potential of pre- attack information gathering and reconnaissance.5.3 Layer Two: Capabilities
As discussed in subsection 4.4, capabilities are planned to replace the set-id bit. This effectively reduces the amount of privilege each program is running with. Successful exploitation of programs that today could result in pivoting [ref 42] or super-user account compromise will result in a less critical privilege elevation in the worst case, limiting the impact of vulnerabilities on the overall security of the host.5.4 Layer Three: Signed Files
Mentioned in subsection 4.2, signed files are the natural evolution of Veriexec, basically associating a signing entity with a file in addition to its digital fingerprint. The immediate benefit is obviously in introducing trust in networked environments, where files can be safely exchanged without fear of attacks such as man-in-the- middle [ref 43].Accessing files - in particular, running programs - that are signed by "trusted" entities in the default configuration could help reduce the possibility of running manipulated binaries even in face of attacks on the digital checksum algorithm. Doing so in the event of a compromise, combined with Veriexec's lockdown mode, will allow real- time investigation and remedy.
5.5 Layer Four: File-System Integrity
Interesting uses for Veriexec (presented in subsection 3.2) are its IDS and IPS modes. With functionality somewhat resembling a fly-trap, Veriexec in IDS mode can be used to silently monitor operations on critical system files (services, configuration files) in real-time, preventing any access to them once changed. This can make post- mortem analysis an easier task. IPS mode can be used to prevent access to these files altogether and generate proper log-files to help identify the source of the attack.These two modes of operation can ensure file-system integrity even in the face of a super-user compromise, making it easier for an administrator to handle an attack without fear of trojanned, backdoored, or otherwise modified (via configuration files) services.
5.6 Layer Five: Protected Kernel Memory
Aimed at preserving kernel memory integrity, the work-in-progress for deprecating kmem(4) usage should result in the ability to remove the interface altogether [ref 44], preventing the possibility of kernel memory manipulation by a malicious superuser on a compromised host. The benefit is obvious: no sophisticated rootkits or kernel-level backdoors can be implemented [ref 45].6. Conclusion
Throughout this paper Ive outlined the recent enhancements in NetBSD security in terms of infrastructure and features, and how they conform to NetBSD's perception of security. Finally, I've exposed some on-going research and development, and showed how it all works together to create a more secure platformWhile it is true that a lot of work is still ahead of us, this paper exposed the lot of work that is behind us. Over the past year NetBSD improved a lot on the security front, and it is expected that these efforts will pay off - if not already - within the next major release.
6.1 Availability
NetBSD 4.0 will include kernel authorization [ref 46], PaX MPROTECT [ref 47], GCC 4.1 with ProPolice, the information filtering hooks [ref 48], fileassoc(9) [ref 49], and pw_policy(3) [ref 50].Complete abstraction of the security model using kernel authorization is being considered for NetBSD 5.0, as well as PaX ASLR and a SegvGuard, Veriexec support for per-page fingerprints and digital signatures, file-system ACLs, and capabilities.
7. Credits
Thanks to the folks who reviewed this paper, either in part or in whole, helping improve its accuracy, readability, and quality. Jason V. Miller, Brian Mitchell and the guys at ISS, the PaX author, and Sean Trifero, Johnny Zackrisson, and Christos Zoulas.Thanks to Brett Lymn, the PaX author, Bill Studenmund, YAMAMOTO Takashi, Matt Thomas, Jason R. Thorpe, and Christos Zoulas for helping with implementing the features discussed in this paper.
8. About the author
Elad Efrat is part of the NetBSD team. He will be presenting some of the content in this paper at EuroBSDcon in Italy, in November 2006.9. Reprints and translations
© 2006 Elad Efrat. Published exclusively on SecurityFocus. Reprint or translation requests require prior approval from the author.
10. Comments?
Public comments for Infocus articles require technical merit to be published. General comments, article suggestions and feedback are encouraged but should be sent to the editorial team instead.
[ref 42] Transition from one user to another.
[ref 43] Assuming, of course, that the kernel itself cannot be manipulated.
[ref 44] From most systems. X would still require it without the use of an aperture driver.
[ref 45] Unless, of course, a kernel vulnerability is successfully exploited.
[ref 46] http://netbsd.gw.com/cgi-bin/man-cgi?kauth++NetBSD-current
[ref 47] http://netbsd.gw.com/cgi-bin/man-cgi?paxctl++NetBSD-current
[ref 48] See the security.curtain knob.
[ref 49] http://netbsd.gw.com/cgi-bin/man-cgi?fileassoc++NetBSD-current
[ref 50] http://netbsd.gw.com/cgi-bin/man-cgi?pw_policy++NetBSD-current. No programs were made aware of the interface yet, though.
