2006-10-03
Article continued from Page 5
3.4 Miscellaneous Security Features
3.4.1 Information Filtering
One of the most common requirements from multi-user systems (such as public shell providers) is that users will not be able to tell what other users are doing - such as running programs, active network connections, login/logout times, etc.NetBSD implements the above using the kernel authorization interface, and presents the administrator with a single knob that can be either enabled or disabled. When enabled, the authorization wrappers will match credentials of the two objects (the looker and the lookee) and return the decision.
This abstraction makes it easier to change the behavior of this feature in the future.
3.4.2 Strong Digital Checksum Support
Support for SHA2 checksums has been available in the NetBSD kernel for a while, mainly for the use of the IPSec network stack. Userland, however, was largely neglected. Tools such as cksum(1) and mtree(8) were able to make use only of hashes that were proven weak [ref 36]. Given mtree(8) can be used to evaluate file-system integrity, this was rather dangerous.The recent improvements to Veriexec, allowing it to support SHA2 hashes, amplified the need for userland support for SHA2 hashes, and were the trigger to adding SHA2 hash routines to libc, as well as support in cksum(1) and mtree(8).
3.4.3 Fileassoc
Fileassoc is one of the latest additions to the NetBSD kernel. It allows associating custom meta-data with files, independent of file-system support (such as extended attributes) using in-kernel memory. The interface is the result of research of other security features that stressed the need for an abstraction of code previously used exclusively by Veriexec.3.4.3.1 Design
The Fileassoc interface extends an already-existing design used by Veriexec. The requirements for the design were performance - so that using it in performance- critical code would not cause a notable impact on system performance - and ease of use. The interface was extended, allowing more than one hook to add its own file meta-data.Designed with simplicity in mind, the interface allows multiple subsystems to hook private data on a per-file and/or per-device basis.
3.4.3.2 Implementation
To achieve the desired goal of near-zero performance impact of entry lookup, the Fileassoc subsystem makes use of hash tables and linked-lists to resolve collisions. The interface operates on struct mount * and struct vnode * to identify file-system mounts and files, respectively. While the internal implementation identifies a file as a pair of struct mount * and a file-id - the contents of va_fileid after a successful VOP_GETATTR() call - this is planned to change in the near future (see subsection 3.4.3.3).In the current implementation, Fileassoc allows four hooks (which can be modified with a kernel option) to add private data to each file. This is transparent to the users of the interface, allowing changing in the future, if such is required.
3.4.3.3 Future Development
As previously mentioned, Fileassoc still relies on the va_fileid field as the unique identifier for files. This is an internal implementation detail, and expected to replaced in the future with file-handles by using calls to the file-system specific vptofh() routines.3.4.4 Password Policy
Administrators often need to enforce a password policy on the system - either a system-global policy, per-application policy, or even a network-global policy. To address that issue, the password policy, or pw_policy(3), interface was developed.With flexibility and simplicity in mind, the pw_policy(3) interface was designed to allow an administrator to specify password policies via a collection of keywords, and applying them to named entities.
The interface is part of libutil and is small enough to be used from within any existing application. It was designed in a modular way, allowing future support for more keywords and evaluation routines.
[ref 36] http://www.schneier.com/essay-074.html
