Usable Mandatory Integrity Protection for Operating Systems

1. Usable Mandatory Integrity Protection for Operating Systems Authors: Ninghui Li, Ziqing Mao and Hong Chen “IEEE Symposium on Security and Privacy(SP’07)” By:PoornakumarRasiraju

2. Introduction • Host compromise is one of the most serious security problems today. • What is the problem with the compromised hosts? Form Botnets which can be used to carry out the attacks such as phishing, Spamming and Distributed denial of service. • Can we deal with these threats at the network level? Partially, by using technologies such as Firewall and Network Intrusion Detection System.

3. Introduction.. • Two reasons why hosts can be easily compromised? • Software is buggy. • Discretionary access control mechanisms are insufficient to defend against network-based attacks. • Are there any efforts to make computer systems secure? Adding MAC to Operating Systems such as SELinux, AppArmor, Systraceand LOMAC.

4. Introduction…. • Then what is the problem? They are complex and difficult to configure. For example, SELinux. --29 different classes of objects --hundreds of operations --Thousands of policy rules SELinux policy interface is daunting even for security experts.

5. Outline • Six design principles for Usable Access Control Systems. • Security Goal of the UMIP Model • Usability goals of the UMIP Model • UMIP Model • Overview • Dealing with Communications • Restricting Low integrity process • Contamination through files • Files owned by Non-System Accounts • Design principles in UMIP • Novel features of UMIP • Implementation • Evaluation • Conclusion

6. Outline • Six design principles for Usable Access Control Systems. • Security Goal of the UMIP Model • Usability goals of the UMIP Model • UMIP Model • Overview • Dealing with Communications • Restricting Low integrity process • Contamination through files • Files owned by Non-System Accounts • Design principles in UMIP • Novel features of UMIP • Implementation • Evaluation • Conclusion

7. Six Design Principles for Usable Access Control Systems • Principle 1: Provide “good enough” security with a high level of usability, rather than “better” security with a low level of usability. Aim at providing a system that is easy to configure which can greatly increase the level of security by reducing the attack surfaces. • Principle 2: Provide policy, not just mechanism. The mechanism-not-policy approach is problematic for security. • Principle 3: Have a well-defined security objective. In order to make a meaningful tradeoff between security and usability, we must identify the security objective and it is the first step in designing a policy.

8. Six Design Principles for Usable Access Control Systems .. • Principle 4: Carefully design ways to support exceptions in the policy model. Onemust carefully design the policy model and the exception mechanisms so that the number of exceptions are small. • Principle 5: Rather than trying to achieve “Strict least privilege”, aim for “good –enough least privilege”. Trying to achieve Strict least privilege results in large number of policy rules. Minimize the policy rules. • Principle 6: Use familiar abstractions in the policy specification interface. The policy specification interface should use concepts and abstractions that administrators are familiar with.

9. Outline • Six design principles for Usable Access Control Systems. • Security Goal of the UMIP Model • Usability goals of the UMIP Model • UMIP Model • Overview • Dealing with Communications • Restricting Low integrity process • Contamination through files • Files owned by Non-System Accounts • Design principles in UMIP • Novel features of UMIP • Implementation • Evaluation • Conclusion

10. Security Goal of the UMIP Model • Aim: To protect the system integrity against network based attacks. • Assumptions: • Network server and client programs contain bugs • Users may make careless mistakes Example: Downloading and running of malicious programs from the internet. • Attacker doesn’t have physical access to the host to be protected. • What does the proposed Model achieve? Attacker can only get limited privileges and cannot compromise system integrity.

11. Outline • Six design principles for Usable Access Control Systems. • Security Goal of the UMIP Model • Usability goals of the UMIP Model • UMIP Model • Overview • Dealing with Communications • Restricting Low integrity process • Contamination through files • Files owned by Non-System Accounts • Design principles in UMIP • Novel features of UMIP • Implementation • Evaluation • Conclusion

12. Usability Goals of the UMIP Model • Usability Goals for UMIP are twofold: • Configuring a UMIP system should not be difficult. • Existing applications can still be used under UMIP. • Administrator can configure the system in an easier manner depending upon needs. • UMIP can be implemented by using the Linux security Module Framework.

13. Outline • Six design principles for Usable Access Control Systems. • Security Goal of the UMIP Model • Usability goals of the UMIP Model • UMIP Model • Overview • Dealing with Communications • Restricting Low integrity process • Contamination through files • Files owned by Non-System Accounts • Design principles in UMIP • Novel features of UMIP • Implementation • Evaluation • Conclusion

14. Overview • uid, gid is too coarse-granulated, a natural extension is to treat a triple of uid, gid and the current program that is running in the process as a principal. • In order to determine what the current process should be allowed to do, one has to consider the parent process and so on… We call this the request channel. • How to capture the information in a request channel is a key challenge.

15. UMIP Model:- Each process has one bit that denotes its integrity level. When a process is created, it inherits the integrity level of the parent process. • If the request channel is likely to be exploited by an attacker, then the process has low integrity. • If the request channel is legitimately used for system administration, then the process has high integrity. The UMIP Model is extended with exceptions to support existing software.

16. Fig: The Summary of the UMIP Model

17. Outline • Six design principles for Usable Access Control Systems. • Security Goal of the UMIP Model • Usability goals of the UMIP Model • UMIP Model • Overview • Dealing with Communications • Restricting Low integrity process • Contamination through files • Files owned by Non-System Accounts • Design principles in UMIP • Novel features of UMIP • Implementation • Evaluation • Conclusion

18. Dealing with communications • The process integrity level drops, when it receives remote network traffic. • In the UMIP Model, the process running the program (RAP), maintains its integrity level when receiving network traffic. • RAP is introduced to trade off security in favor of usability. • The UMIP Model leaves the decision of whether to allow remote administration or not to the system administrators.

19. Outline • Six design principles for Usable Access Control Systems. • Security Goal of the UMIP Model • Usability goals of the UMIP Model • UMIP Model • Overview • Dealing with Communications • Restricting Low integrity process • Contamination through files • Files owned by Non-System Accounts • Design principles in UMIP • Novel features of UMIP • Implementation • Evaluation • Conclusion

20. Restricting Low integrity process • Security critical operations are classified into two categories:- File operations and non-file administrative operations. • In modern Linux, the operations are controlled by capabilities. • The default UMIP rule grants only two capabilities CAP_SETGID and CAP_SETUID to low-integrity process.

21. Restricting Low integrity process.. • Low integrity process running as root cannot set its uid to a new normal user. • To identify which files should be considered sensitive is a challenging task. • Utilizes the valuable information in existing Discretionary Access Control (DAC) mechanisms for MAC. • A low integrity process is forbidden from changing the DAC permission of any (read- or write-) protected file. • Exception policies • The binary “/usr/sbin/vsftpd” is allowed to use the capabilities CAP_NET_BIND_SERVICE, CAP_SYS_SETUID, CAP_SYS_SETGID and CAP_SYS_CHROOT, to read the file /etc/shadow, to read all files under the directory /etc/vsftpd, and to read or write the file /var/log/xferlog.

22. Outline • Six design principles for Usable Access Control Systems. • Security Goal of the UMIP Model • Usability goals of the UMIP Model • UMIP Model • Overview • Dealing with Communications • Restricting Low integrity process • Contamination through files • Files owned by Non-System Accounts • Design principles in UMIP • Novel features of UMIP • Implementation • Evaluation • Conclusion

23. Contamination through files • Process integrity level drops after reading and executing files that are not write-protected. • Even if a file is write-protected, it may still be written by low-integrity process, due to the exception policies. • Sticky bit is used to track contamination for files. • A low-integrity process is forbidden from changing the sticky bit of a file. • The sticky bit can be reset by a special utility program provided by the protection system.

24. Outline • Six design principles for Usable Access Control Systems. • Security Goal of the UMIP Model • Usability goals of the UMIP Model • UMIP Model • Overview • Dealing with Communications • Restricting Low integrity process • Contamination through files • Files owned by Non-System Accounts • Design principles in UMIP • Novel features of UMIP • Implementation • Evaluation • Conclusion

25. Files owned by Non-System Accounts • UMIP allows exceptions to be specified for specific users. • Global exceptions can be applied to all processes with that users user id as specified in the account’s exception policy. • A low-integrity process is disallowed from using setuid to change its user id to another user account.

26. Outline • Six design principles for Usable Access Control Systems. • Security Goal of the UMIP Model • Usability goals of the UMIP Model • UMIP Model • Overview • Dealing with Communications • Restricting Low integrity process • Contamination through files • Files owned by Non-System Accounts • Design principles in UMIP • Novel features of UMIP • Implementation • Evaluation • Conclusion

27. Design principles in UMIP • Principle 1:Aimed at providing good enough security with high level of usability. • Principle 2&3:Used an existing mechanism and focused on designing a policy to achieve the security objective. • Principle 4:Designed Exception Mechanisms. • Principle 5:Two design choices were made to increase the simplicity of the model. • No limitation is placed on high-integrity process. • Non-sensitive files are not protected. • Principle 6:Uses files and capabilities in policy specifications.

28. Outline • Six design principles for Usable Access Control Systems. • Security Goal of the UMIP Model • Usability goals of the UMIP Model • UMIP Model • Overview • Dealing with Communications • Restricting Low integrity process • Contamination through files • Files owned by Non-System Accounts • Design principles in UMIP • Novel features of UMIP • Implementation • Evaluation • Conclusion

29. Novel features of UMIP • UMIP has the following novel features: • Supports a number of ways to specify some programs as partially trusted. • A file has two integrity level values. • Integrity protection is compartmentalized by users. • Allows low-integrity files to be upgraded to high-integrity. • In addition to integrity protection, it offers some confidentiality protection. • Uses DAC information to determine integrity and confidentiality labels for objects.

30. Outline • Six design principles for Usable Access Control Systems. • Security Goal of the UMIP Model • Usability goals of the UMIP Model • UMIP Model • Overview • Dealing with Communications • Restricting Low integrity process • Contamination through files • Files owned by Non-System Accounts • Design principles in UMIP • Novel features of UMIP • Implementation • Evaluation • Conclusion

31. Implementation • When a process issues a request, it should be authorized by both Linux DAC system and UMIP . • Exceptions must be specified in a policy file. • The policy file includes a list of entries. Each entry contains four fields: • A path that points to the program • The type of a program • A list of exceptions • A list of executing relationships

32. Implementation.. Figure: The four forms of file exceptions in UMIP.

33. Fig: Sample Policy

34. Outline • Six design principles for Usable Access Control Systems. • Security Goal of the UMIP Model • Usability goals of the UMIP Model • UMIP Model • Overview • Dealing with Communications • Restricting Low integrity process • Contamination through files • Files owned by Non-System Accounts • Design principles in UMIP • Novel features of UMIP • Implementation • Evaluation • Conclusion

35. Evaluation • Evaluation of the UMIP Model: • Usability • Transparency • Flexibility • Ease of configuration • Security • Installing a rootkit • Kernel-mode rootkit • User-mode rootkit • Stealing the shadow file • Altering web files. • Performance

36. Fig: The performance results of Unixbench 4.1 measurements

37. Outline • Six design principles for Usable Access Control Systems. • Security Goal of the UMIP Model • Usability goals of the UMIP Model • UMIP Model • Overview • Dealing with Communications • Restricting Low integrity process • Contamination through files • Files owned by Non-System Accounts • Design principles in UMIP • Novel features of UMIP • Implementation • Evaluation • Conclusion

38. Conclusion • The UMIP Model defends against network-based attacks and preserves the system integrity. It supports existing applications and system administration practices, and has a simple policy configuration interface.

39. References • K.J.Biba . Integrity considerations for secure computer systems. Technical Report MTR-3153, MITRE. • U. Shankar, T. Jaeger, and R. Sailer. Toward automated information-flow integrity verification for security-critical applications. In Proceedings of the2006 ISOC Networked and Distributed Systems Security Symposium, February 2006. • T. Fraser. LOMAC: Low water-mark integrity protection for COTS environments. In 2000 IEEE Symposium on Security and Privacy, May 2000. • P. Loscocco and S. Smalley. Integrating flexible support for security policies into the Linux operating system. In Proceedings of the FREENIX track: USENIX Annual Technical Conference.