Summary of key lessons of Chapter 10
Chapter 10 has extended a discussion of UNIX in terms of the security of UNIX processes together with the environment in which they operate. As such, it is significantly learned that a UNIX process is associated with a considerable amount of state which includes it own virtual memory layout as well as the entire machine-specific information that is vital to halt and begin the flow of execution. In other words, it is worth noting that the environment in which programs run in UNIX is made up of numerous idiosyncrasies which have effect on how processes can function safely.
In addition, Chapter 10 has demonstrated vividly the mechanisms by which to pass extraneous data along with essential resources into a process. These include environment variables and file descriptors, for instance. In the same breath, there is a presentation of the mechanisms such as limits which serve to impose certain restrictions on how a process operates. In this respect, it is learned that processes that are linked with elevated privileges deserve to be careful when interacting with particularly sensitive resources. This is the case because UNIX offers a very fine-tuned access over the
environment in which processes operate.
Another significant lesson in the Chapter 10 is that auditing process in UNIX requires one to be aware of all the security implications relating to the myriad actions performed implicitly during running of a program. The chapter has also offered vital lessons relating to issues of direct program invocation via the execve() system call as well as indirect invocation via a command shell interpreter. There are key lessons on security-related behaviors which include file descriptor passing, command-line arguments, together with trusting environment variables.
Also in the chapter, there are vital insights on how mechanisms can be misused to the effect of adversely affecting the way a process runs. One learns that the very utilization of signals, IPC as well as resource limits have the potential to contribute to a program experiencing unexpected errors particularly when performing typically normal tasks. When such happens, it may in turn result into a security compromise or even offer assistance to an attacker in exploiting a vulnerability which needs precise timing.
A final significant lesson that can be drawn from the disscusion in Chapter 10 relates to the process interaction via external mechanisms, which include the likes of IPC mechanisms and RPC. In summary, therefore, Chapter 10 has presented key information to enable one to sufficiently review the modern UNIX software.
Summary of key lessons of Chapter 11
Chapter 11 presents an intriguing discussion of security considerations that are specially unique to Windows operating systems, particularly the Windows NT series. The chapter delves in some of the critical Windows security concepts namely: the security mode, objects together with their associated access controls, and manipulating files (Dowd et al, 2007).
An integrated lineage of Virtual Memory Systeme (VMS) and Windows 3.0 affords the modern Windows OS its unique and ocassional schizophrenic feel. As such, the system offers a flexible security model which enables for a fine-grained separation along with assignment of resources. This in effect stretches to secure aunthentication across vast distributed networks. On the other hand however, it is noted that Windows has a potential weakness in the sense that the system serves to support a vast range of capabilities. It is therefore of great worth to note that many historical decisions that touch on designing and implementing these capabilities have exposed the vulnerabilities of the Windows OS (Dowd et al, 2007). This is especially the case owing to the aspect that instances of the same application or multiple applications usually have to refer to objects which are assigned an identity name and them stored in a specific object namespace. This is a security issue because it affords attackers the chance to design an object that carry the same name way before the legitimate original application has done that. Furthermore, there is room for the illegitimate object to be grossly manipulated to the effect of rendering the legitimate application not function appropriately besides stealing credentials from a highly privileged process. It is therefore a key lesson of Chapter 11 that a thorough understanding of the Windows objcet creation API is essential to comprehend the mechanism pf these namespace collision attacks, also called name squatting.
Chapter 11 also gives a great lesson by making it cleat that any process is capable of opening a nameless regardless of the boundary descriptor in instances where the namespace does not gice a SECURITY_ATTRIBUTES structure having sufficient access control. Consequently, security of privvate namespaces is not only dependent on the namespace security descriptor but also on the boundary descriptor being made visible to client processes. In addition, there is the key lesson that the private namespaces are meant to purely address issues relating to name-squatting and thus do not have the ability to offer any protection against direct access of an existing object having a weak access control. Accordingly, an object’s discretionary access control list (DACL) is the only tool that offers protection to an object so that another user context cannot manipulate it (Dowd et al, 2007). In summary, it must be appreciated that there are a number of areas in the Windows architecture that are highly confusinf making it more prone for developers to makes major security mistakes.
Reference:
Dowd, Mark, McDonald, John, Schuh, Justin. (2007). The Art of Software Security Assessment: Identifying And Preventing Software Vulnerabilities. Boston, Addison-Wesley.
