2006-10-03
Article continued from Page 6
4. Current NetBSD Security Research and Development
Discussed so far are solutions already implemented and available in NetBSD. Below you will find the current goals of the security research done in NetBSD, some of which are planned to be introduced as soon as the NetBSD 5.0 release.4.1 Deprecating The Kernel Virtual Memory Interface kmem(4)
The kmem(4) device allows raw reading of kernel memory. It was introduced to allow programs that needed information from the kernel a way to extract it by reading the symbol list from the live kernel’s on-disk image and seeking to it.Several issues were raised regarding this device [ref 37], and with 4.4BSD a new interface meant to replace kmem(4) was introduced, named sysctl. Sysctl allowed structured and controlled access to kernel information via syscalls carrying a management information base (MIB). The kernel held a tree-like hierarchy of information it can provide, and the MIB described what information is looked up.
From a security point of view, the kmem(4) device allows malicious processes running with kmem or root privileges to directly read or write kernel memory [ref 38]. The attack vector here is widely abused[ref 39],[ref 40] mainly to introduce stealth rootkits into compromised systems.
Currently, NetBSD is doing loose usage of the kmem(4) interface, using it for more than a few userland utilities. There is an on-going effort to gradually convert programs using kmem(4) to sysctl with proper kernel support, allowing us to deprecate daily use of kmem(4) and maintain the interface for debugging needs only, if required.
4.2 Digitally Signed Files
At the moment, the Veriexec subsystem provides integrity based entirely on data. While it is strong enough to maintain file-system integrity on servers and critical systems, it lacks two important features: ability to securely modify the baseline during runtime, and ability to associate an identity with a file-system object.Securely modifying the baseline during runtime is forbidden, even for the super-user, for security reasons: a possible scenario is that the host can be fully compromised and trojanned by an attacker; preventing the super-user from modifying critical programs can prevent that.
Associating a digital signature with a file-system object, regardless of implementation, could solve the above two by allowing an administrator to specify trusted entities. These could run any programs - as long as they are signed by them. That would mean that introducing a new program on the system required digital signing by a trusted entity, rather than a super-user adding its digital checksum to a database and rebooting.
It is planned to extend the Veriexec subsystem with this capability, in either one of two possible directions for the implementation; either delegating the digital signature processing to a user-space daemon, or making use of the BSD-licensed BPG inside the kernel.
4.3 Access Control Lists
Perhaps one of the longest remaining Unix relics in NetBSD is the file-system security model. Proven weak over time, modern operating systems implemented file- system access control lists, or ACLs.An ACL allows finer-grained file access, extending the owner-group-other scheme currently used.
There are two main issues when approaching file-system ACLs. The first is where to store them, and how to associate a potentially variable sized data-structure with a file. The second is what ACL model to use, which may dictate interoperability with other operating systems.
For the former, NetBSD provides both the UFS2 file-system [ref 41], where extended attributes were introduced especially to address this issue, as well as the Fileassoc kernel interface, allowing file-system independent association of meta-data, after such data has been loaded via a driver.
Given recent standardization in ACL structure between Windows NT, Mac OS X, and NFSv4, it was decided to go with the same model for the latter, allowing NetBSD to properly operate in a heterogeneous environment.
4.4 Capabilities
Part of Unix's long-standing weaknesses is the use of set-id programs to elevate privileges of a normal user, either temporarily or permanently, required to complete an operation restricted to the super-user - for example, open a raw socket, bind to a reserved port, and so on.The above lead to the absurdity that bugs in often trivial and non-critical programs could result in privilege abuse or even full system compromise.
Introducing capabilities, implemented as a set of kernel authorization listeners, will replace the role of the set-id bit in today's systems. Providing a fine-grained privilege model, each program will run with the minimal set of capabilities required for its operation. Furthermore, associating capabilities with users will allow us to define user roles, dividing the work-load of the super-user - possibly eliminating it entirely!
While a design for NetBSD capabilities hasn’t been laid out yet, it is expected that support for capabilities will be provided on the file-system layer, allowing the association of capabilities with a program using extended attributes, as well as an API a la OpenSolaris ppriv(3) for dropping unneeded capabilities during runtime, and a mechanism for associating capabilities with users on the system.
[ref 37] “The Design and Implementation of the 4.4BSD OS”, pages 509-510.
[ref 38] The use of raw access to bypass a security guard isn't limited to kernel memory: on-disk inodes could be modified using raw disk access, for example.
[ref 39] http://artofhacking.com/files/phrack/phrack58/P58-0X07.TXT (mirror)
[ref 40] “Rootkits: Subverting the Windows Kernel”, chapter 7.
[ref 41] http://www.usenix.org/events/bsdcon03/tech/mckusick.html
