2006-10-03
Article continued from Page 3
3.1.4 Future Development
While implementing the kernel authorization back-end and making the kernel dispatch its authorization requests to it was an important ground preparation, there is more work to be done before declaring this interface useful.The first step in the integration of kernel authorization was mostly mechanical and transparent to users, intended to preserve existing semantics. The next logical step is to examine the kernel to ensure the interface abstracts the security model used in NetBSD.
Given its heritage, the NetBSD kernel is too tightly coupled with the Unix security model, and the concept of a single super-user with a user-id of zero is often hard- coded. For example, a lot of privileged operations check for an effective user-id of zero directly in the process’ credentials structure, not making use of the suser(9) interface.
The next logical step will be to identify these locations, and properly replace these vague effective user-id checks with calls to the kernel authorization interface, describing the privilege required to complete the operation. The same applies to any authorization wrapper calls acting as placeholders, checking for super-user rights.
The above work will result in the complete abstraction of the security model used in the NetBSD kernel, allowing switching easy as a one-line change in the kernel configuration between the Unix security model, a finer-grained capabilities model, or a third-party security model possibly implemented using an LKM.
3.2 Veriexec
Veriexec is NetBSD’s file-integrity subsystem, allowing the verification of a file's digital fingerprint before accessing it. Introduced in NetBSD by Brett Lymn in 2002 [ref 19] and later integrating work from Vexec of the Stephanie project [ref 20] in 2005, Veriexec provides means to ensure real-time file integrity and monitoring combined with intrusion detection and prevention capabilities.Initially self-contained, Veriexec’s core - the interface for associating meta-data with files regardless of file-system support using in-kernel memory - was recently abstracted [ref 21] to form the Fileassoc interface to satisfy similar needs from other features.
3.2.1 Related Work
Integrity checker implementations have been around for decades. Used for various purposes such as virus protection in DOS and file changes notifications in Unix, the concept itself is not new to the security industry. Dr. Fred Cohen's research was among the first to offer insight about using integrity checkers to protect from malicious software [ref 22]. Tripwire [ref 23], presented by Eugene Spafford and Gene Kim, allowed system administrators to be notified about corrupted or altered files in a timely fashion.Yet, while there are numerous products for every computing environment, they all share a common set of flaws that prevents them from realizing their potential.
First, none of them integrates with the operating system deep enough to provide real- time protection: most are retroactive tools used to notify after changes were detected.
This approach does not address potential damage that be caused in the time-window between a file was altered and improperly used since and when the administrator receives notification of the matter and handles it. It also does not guarantee the integrity of the integrity checker itself: a successful compromise has the potential of remaining under the radar.
Furthermore, some implementations use weak algorithms [ref 24] to calculate a file's checksum, or rely on a small data-set for checksum calculation. Other implementations rely on a file's attributes rather than data to evaluate integrity. The impact of the above is that a file can be modified in such ways that even if the integrity checker tries to evaluate it after the change, it will not be able to detect it. Whether it's by altering the file in a way to defeat the checksum algorithm, or modify areas of the file that the integrity checker is known to ignore, or even tamper with the file's attributes - these implementation flaws can all be bypassed by an attacker quite easily.
And last, they all leave out an important aspect in today's reality: the network. Our environments become more and more inter-connected; we access files from untrusted locations on a daily basis; some architectures rely on a networked environment for everyday operation: centralized storage, backup, and so on. Existing products may provide a certain level of local protection on a host, but leave an important - and interesting - question unanswered: how do you cope with the compromise of a remote resource?
While we cannot deal with all aspects of compromise of a remote resource we use, and it is certainly not our goal either, it is important to try and address the ones that can be solved by using an integrity checker integrated in the operating system.
3.2.2 Design
Veriexec was designed to be a file-system independent integrity subsystem protected from users, including root, by operating solely from the kernel. Recent attacks against various hashing algorithms once thought secure proven the need for interface flexibility - such that can be used both for easy addition of support for new hashing algorithms, as well as future work on digitally signed files.Careful analysis of the bottlenecks for file access and other file-system semantics (such as rename and remove) resulted in generic hooks, to be called with the required context for decision-making and policy enforcement. At the time of writing, it is impossible to implement the Veriexec policy on top of kauth(9) due to lack of required scopes.
The design process also took into account various environments for Veriexec - from workstations, through servers and critical systems, to embedded task-oriented appliances. Strict levels with varying implications were introduced to support multiple uses, and were named semi-descriptively to hint for said uses: learning mode (level 0), intrusion detection system (IDS) mode (level 1), intrusion prevention system (IPS) mode (level 2), and lockdown mode (level 3).
[ref 19] http://mail-index.netbsd.org/tech-security/2002/10/30/0000.html
[ref 20] http://ethernet.org/~brian/Stephanie/
[ref 21] http://mail-index.netbsd.org/tech-kern/2006/06/08/0007.html
[ref 22] http://vx.netlux.org/lib/afc03.html. Dr. Fred Cohen also introduced the concept of integrity shells, with which Veriexec is sharing some commonalities; no implementation was made available, however, and therefore it is impossible to tell whether the faults mentioned also apply to them.
[ref 23] http://portal.acm.org/citation.cfm?id=191183
[ref 24] For example, CRC: https://www.kb.cert.org/vuls/id/25309
