Confining Root Programs with Domain and Type Enforcement (DTE)

1. Confining Root Programs with Domain and Type Enforcement (DTE) Kenneth M. Walker, Daniel F. Sterne, M. Lee Badger,Michael J. Petkac, David L. Shermann. Confining Root Programs with Domain and Type Enforcement.Proceedings of the 6th Usenix Security Symposium, San Jose, California, 1996.

2. On Root Privilege • Root Privilege is a huge security risk. • Unix systems have common processes that run as root. • Subverting these processes can gain the attacker complete control of the system.

3. Domain and Type Enforcement(DTE) Operating System access control Technology: • Policy restricts access to system resources based on the program's capabilities.

4. DTE Background • Derived from work done by Bobert and Kain. • Associates a domain with a running process. • Associates a type with each object (file, packet). • Works based on the principle of least privilege. • Least privilege grants only the rights to perform the program's function.

5. DTE Constructs 4 Primary Constructs for Specifying Policies: • Type Statement - Declares equivalence classes of data that are treated differently by the policy. • Domain Statement - Defines the access modes a process running in this domain is permitted to use on a type by type basis. • Initial Domain Statement - Determines the domain in which the system's first process starts. • Assign Statement - Binds types of data to specific files or directory hierarchies of files.

6. Protecting System Binaries from Hacker Toolkits • Toolkits allow attackers to break into systems by exploiting known security holes. • Widely available, including on the internet.

7. Rootkit • Rootkit is a popular hacker toolkit. • Once an attacker has penetrated a system with Rootkit, it builds a hidden backdoor for future access. • Modifies the standard Unix login program to recognize special login names, skip the normal access checks for those names and provide a hidden session with root privileges. • Modifies Unix utilities to hide the presence of the intruder after login

8. Protecting the System from Rootkit • Create an administrative domain with write access to system binaries and their associated directories. • No other domains in the system will have this access. • Due to running in a more restricted domain Rootkit will be unable to replace any processes.

9. Sample DTE Policy

10. DTE Policy

11. DTE Policy • Controls access to the authentication and role authorization databases. • Databases are labeled with DTE types, and access to these types are strictly controlled by the DTE policy to prevent unauthorized modification.

12. daemon_d • daemon_d domain is the domain in which the first system process, init, runs. • All descendants of init will run in the daemon_d domain until one invokes /usr/bin/login. • Has no permission to write to system binaries.

13. login_d • Upon login obtains a role request for the user: • If the user is authorized to assume the role, the login program invokes the user’s shell or program in the initial domain associated with the role.

14. user_d • Standard user privileges, to non-admin users this appears identical. • Root runs in the user domain.

15. admin_d • Allows read, write, execute and directory access to all types of files on the system. • Includes privileges to modify DTE policy files.

16. passwd_d • Addition of a new domain : passwd_d to the system. • UNIX password programs are the entry points to the passwd_d domain. • However, root still has permission to change passwords for other users. • Solution: create a wrapper for the password programs • Wrapper checks DTE user ID authorization, then executes the password program with the wrapper’s role.

17. Protecting System Logs • Attackers can hide their footsteps by modifying or disabling their target's auditing system. • This threat can be countered by a policy extension:

18. Security Tradeoffs • Extent of Protection vs. Simplicity of Policy • Policy Simplicity vs. The use of unmodified Programs

19. Conclusions • Use of root privilege is the cause of one of the most important security breaches in UNIX systems. • DTE can be used to alleviate this issue, but doing so increases system configuration complexity.

20. Finding User/Kernel Pointer Bugs With Type InferenceRob Johnson and David Wagner. Finding User/Kernel Bugs With Type Inference(Postscript) USENIX Security Symposium, 2004.

21. CQual Background • CQual is a type-qualifier analysis tool that assists programmers in searching for bugs in C programs. • Security critical programs require the capability to handle data from untrustworthy sources. • Aims to find all bugs which tends towards a greater number of false positives.

22. CQual Example Below, is an example showing how to use CQual to find a potential format-string vulnerability in a C program: • This program reads the value of LD LIBRARY PATH from the environment and passes it to printf as a format string. If the user can control the environment in which this program is run, then this program may have a format-string vulnerability. For example, if the user sets LD LIBRARY PATH to a large sequence of (%s)'s, the program will likely segmentation fault. • Untrusted Code : (http://tbp.berkeley.edu/~jdonald/cqual/user-guide.pdf)

23. CQual Example (Continued) • By default CQual assumes nothing about the behavior of your program. In order to start checking for bugs, we need to annotate the program with extra type qualifiers. For this example we will use two qualifiers. We will annotate untrustworthy strings as $tainted, and we will require that printf take $untainted data: • CQual Output : (http://tbp.berkeley.edu/~jdonald/cqual/user-guide.pdf)

24. CQual Extensions • Added context-sensitive analysis to reduce false positives and programmer annotations. • Improved CQual’s handling of C structures by allowing fields of different instances of a structure to have different types. • Improved CQual’s analysis of casts between pointers and integers. • These improvements make the number of findings more reasonable to use on software as complex as a kernel.

25. User/Kernel Pointer Bugs • All Unix/Windows based operating systems are susceptible to user pointer bugs. • On 32-bit computer Linux divides the virtual address space seen by user processes, as illustrated on the right. • The virtual memory space from 0-3 GB is available to the user process. The kernel executable code and data structures are mapped into the upper 1 GB of the process’ address space. • User process is not allowed to read or write into the kernel memory space.

26. An Example of User/Kernel Pointer Bugs • Malicious process may pass an invalid argument “buf” to the kernel. • “buf” may point to unmapped memory in the user process’ address space, on a copy a page fault is generated. • “buf” may actually point into the kernel’s region of memory. This leads to several attacks.

27. An Example of User/Kernel Pointer Bugs(Continued) • If “buf” points to kernel executable code, the attacker can make the kernel overwrite it’s own code with the contents of the variable x. • The attacker can set “buf” to point to kernel data structures that store her user id, and overwrite his or her permission. • The attacker can attempt to crash the system with random values.

28. How to circumvent these calls? • To avoid these kinds of errors the Linux kernel contains sever user pointer access functions that kernel developers are supposed to use instead of memcpy or de-referencing pointers directly. • (copy_from_user, copy_to_user) • These behave like memcpy but perform required safety checks.

29. Kernel Pointers • User Pointers : A pointer variable whose value is under user control and hence untrustworthy. • Kernel Pointers : A pointer variable whose value is under kernel control and guaranteed by the kernel to always point into the kernel’s memory space, and hence is trustworthy. So how do we tell the difference?

30. Qualifier on Pointer Types • By adding the extra qualifiers to the code, you can ensure that pointers are not mismatched. • This paper used user and kernel type qualifiers, then used CQual to type-check the kernel.

31. Enhancements to CQual • Context Sensitivity- Ability to match up function calls and returns. • Field Sensitivity – Ability to distinguish different instances of structures. Allows type constraints for different fields of different instances. • Well-formedness Constraints – Ability to enforce special type rules related to structures and pointers. • Sound and Precise Pointer/Integer Casts – Ability to analyze casts between pointers and integers.

32. Results of CQual Analysis • Each bug represents an exploitable security vulnerability. • There were 4 common bugs between the kernels, for a total of 17 distinct bugs between the two kernels.

33. Summary/Conclusion • Introduced a semantically sound method for analyzing user/kernel security bugs. • Identified 17 distinct new user/kernel bugs in several versions of the Linux kernel. • Showed how to reduce false positives by an order of magnitude, and thereby make type-based analysis of user/kernel bugs practical by enhancing existing type inference algorithms.

34. Discussion