Using the Flask Security Architecture to Facilitate Risk

Using the Flask Security Architecture to Facilitate Risk Adaptable Access Control Computer Security & OS Lab. DKU March 31 Younsik Jeong Ph. D. Student

Abstract v Risk Adaptable Access Control (RAd. AC) is an important emerging technology that has gained the attention of many people as a way to change the current information dissemination policies v RAd. AC have the ability to enforce a flexible mandatory access control policy based on various changing factors, such as situational and environmental factors v commonly deployed systems are unable to reliably support this type of access control, but by using existing technology the desired capability could be built v This paper describes how the Flask Security Architecture can be used to provide RAd. AC. Computer Security & OS Lab. DKU 2

Introduction v The Global Information Grid (GIG)[2] architecture describes a significant change in the way government systems will interact v In existing architectures, “need to know” n Limits information sharing to only those mission elements able to demonstrate a need v the massively connected nature of the GIG and its requirement to support many interrelated missions mandate a change in information dissemination philosophy Need to know need to share Computer Security & OS Lab. DKU 3

Introduction v Current access control schemes adhere to a well defined policy that is often static, but the new paradigm calls for a more flexible model v RAd. AC systems can be characterized by their ability to enforce access control decisions according to a security policy that can dynamically change v Factors that might affect risk include environmental and situational factors as well as things like characteristics of people or IT components v RAd. AC implies that there exists a characterization of factors that would indicate the policy should be switched v This paper describes a prototype that demonstrates that the Flask Security Architecture[10] is an example of suitable technology for RAd. AC Computer Security & OS Lab. DKU 4

Risk Adaptable Access Control v A RAd. AC model uses various static and dynamic factors to influence access control decisions v These factors form the basis for deciding what security policy n n By considering each of these factors, the system can dynamically select a policy that results in different access decisions as appropriate to the perceived risk Any system that correctly implements RAd. AC must always keep all of its data under its control, even when it is allowed to flow to restricted places This condition has to be met because the conditions that allowed data to flow there might change which would require a revocation For example n n policy could dictate that in a time of national crisis first responders need access to some forms of sensitive information in order to save lives. Under these conditions, “need to share” outweighs the “need to know. ” At the conclusion of the crisis, “need to share” would no longer take precedence Computer Security & OS Lab. DKU 5

Risk Adaptable Access Control v To correctly implement MAC three conditions must hold n n n The system must be in control of all subject and objects at all times All security decisions must be based on all security relevant information The policy governing security decisions must be under one central control v A correct implementation of MAC on all systems, although necessary, is not sufficient for a RAd. AC system v Supporting policy changes is fundamental to the nature of RAd. AC v Furthermore, the implementation must be capable of enforcing any revocations necessitated by a policy change Computer Security & OS Lab. DKU 6

Problems impeding RAd. AC v Even systems that do offer some form of MAC lack the flexibility necessary to support policy changes v Commonly deployed systems have discretionary access controls (DAC) n n DAC system is capable of supporting policy changes But, in capable of making the guarantees needed to meet data flow constraints and revocation requirements Sticky bit Read Write Execute remove Owned A User A Read Write Execute remove User B n /tmp -rwxrwxrwt A A 4096 May 1 11: 20 some_file In a certain situation, User B need to have a right to delete ‘some_file’ Even though linux supports DAC, any user can't change the base rule. Computer Security & OS Lab. DKU 7

Demonstrating RAd. AC v Although commonly deployed systems cannot be used to create a system with RAd. AC capabilities, technology does exist. v Our(authors) work is to demonstrate that Flask Security Architecture can provide the functionality needed to support a RAd. AC capable system. v To do this, we construct prototype system. n Uses SELinux n n an Implementation of Flask in the Linux operating system, to meet the system MAC req. It meets the requirements for network MAC, by using Flask applied to a network application v A RAd. AC capable system was successfully built using the capabilities provided by these two applications of Flask. Computer Security & OS Lab. DKU 8

Demonstrating RAd. AC v To best demonstrate the RAd. AC capability, several things were needed from the network application n n Data source and consumer Ability to enforce policy on involved systems needed to be shown needed to be possible for the RAd. AC system to maintain control of any data released from the source Policy flexibility and the ability to revoke access to data once released was key to the demonstrations success Several security policies, representing different possible RAd. AC situations, were constructed for the demonstration Computer Security & OS Lab. DKU 9

Flask Security Architecture v Flask has two main components n Security server - provides a centralized point where all security policy decisions are made n n Security policy - set of rules, governing access and labeling decisions, that are specified through configuration files Object manager – implements functionality n n Responsible for requesting access and labeling decisions from the security server when needed Also responsible for binding labels to the objects they manage and enforcing all decisions provided by the security server v Other component n Access Vector Cache n n n Incorporated into object manger Stores previously computed(allowed) access decisions security server is only consulted on cache misses Computer Security & OS Lab. DKU 10

Flask Security Architecture v Flask supports policy changes through reloading of the security policy configuration v Security server maintains control over AVCs, enabling policy changes to be propagated throughout the system v Revocation is handled through flushing of the AVC causing future access decision to require consultation to the security server running with the new policy v Additional revocation comes from the ability of the object manager to request notification of policy changes n On policy changes, object managers can then perform special processing to ensure no access allowed under the original policy is still granted after it would be prohibited by the new policy Computer Security & OS Lab. DKU 11

SELinux(Security Enhanced Linux) v Application of the Flask Security Architecture v Linux kernel acts as an object manager, security server and AVC have been incorporated into the kernel v The security server implements a security model that is a combination of Type Enforcement, Role-Based Access Control, and Multi. Level Security v Policies can be defined to provide strong process isolation and to support least privilege can be used to meet the integrity goals of the system v The interactions between all processes on the system can be tightly controlled Computer Security & OS Lab. DKU 12

SELinux Terminology v Identity (or Users) – SELinux user account n Similar to, but separate from UID (Unix user). They are separate items n n n su command changes UID, but not identity Identifier for a single user or an equivalence class of users. E. g. , user_u, root, unconfined_u, system_u, sysadm_u, test_u v Domains: Classification of a subject. n n E. g. , sysadmn_t, user_t, named_t, sshd_t, user_home_t, emacs_t Each process is associated with a domain v Types: Classification of an object (file, directory, etc. ) n n E. g. , paper_t, shell_exec_t, tmp_t Each object is associated with a type v Class: Type of an object, e. g. , file or (executable) process. v Roles: Specification of privileges or actions that can be taken by user fulfilling a role n E. g. , user_r, staff_r, system_r, sysadm_r , object_r, unconfined_r Computer Security & OS Lab. DKU 13

Security contexts and Unix users Computer Security & OS Lab. DKU http: //debianhandbook. info/browse/stable/sect. selinux. html 14

Type Enforcement v The type defines a type for files v The domain defines a type for processes v The rule defines permission between domain and type v Policy defines access rules in terms of process and file types n allow <subject type> <object type>: <class set> <permission set> E. g. ) allow httpd_t http_config_t: file { read, write }; v SELinux prevents access unless explicitly allowed Computer Security & OS Lab. DKU 15

Object Classes and Permissions v SELinux defines 41 kernel object classes v Each with their own fine-grained permissions n For example, file object class has 20 permissions: http: //www. cse. psu. edu/~tjaeger/cse 543 f 07/slides/03 -Policy. Concepts. pdf Computer Security & OS Lab. DKU 16

RBAC v Roles associates domains with users n n Process type allowed only if allowed by role definition Even if type enforcement allows it role > rule Computer Security & OS Lab. DKU 17

Passwd program example Allow passwd_t shadow_t : file { create ioctl read getattr lock write setattr append link unlink rename }; v Allows processes with passwd_t domain type read, write, and create access to files with shadow_t type n Purpose: passwd program runs with passwd_t type, allowing it to change shadow password file (/etc/shadow) v Shadow password file attributes: -r---- root system_u: object_r: shadow_t /etc/shadow Standard Linux SELinux Only root allowed to Create new copies of file Only allows passwd_t Domain(via above allow rule) to modify file http: //www. cse. psu. edu/~tjaeger/cse 543 f 07/slides/03 -Policy. Concepts. pdf Computer Security & OS Lab. DKU 18

Network MAC v Extend Flask to network application n network application is treated as a user-space object manager Permissions are defined to control access to the objects maintained by network object managers are responsible for enforcing security decisions v The security server for network object managers is likely to reside on a different machine n This places a network security requirement on the implementation to protect the communications between the network security server and all object managers in addition to any network security requirements already present to support the network application. v Network object managers can be used to support revocation v The network security server retains control over the operation of AVCs. v As part of this work, the AVC library was modified to have better support for network object managers by allowing the network security servers that implement security models and policies distinct from the security server on the host SELinux system Computer Security & OS Lab. DKU 19

SE-XML v XML parser that has had Flask applied to it n Enables a customized view of XML documents based on a security policy v SEXML applies security labels to XML nodes used by the security server to determine access to nodes within a document. v The XML parser is an object manager enforcing access decisions about each operation on each XML node v A new security class with permission over documents was defined Computer Security & OS Lab. DKU 20

Implementation Client’s ip address is used to determine the security label in all future access checks for that session Granted access to the server with being approved to use the IPSec connection Document server Viewer/client SE-XML SElinux handles all labeling and access decisions about the documents. Network security Server Risk knob SElinux Access decision comes from the network security server Computer Security & OS Lab. DKU 21

Document Server v SE-XML document server was implemented as a user-space object manager running on SELinux, Object. . ? Documents v SE-XML is used to bind network labels to documents v Two kinds of access decisions n Check to see if the requester is authorized to use the server n n n Handled by SELinux on the server’s machine IP address is used to determine the security label in all future access checks for that sessions Access decision comes from the network security server n n Network security server handles all labeling and access decisions about the documents what enables the document server to determine which files can be released to authorized users Computer Security & OS Lab. DKU http: //flylib. com/books/en/2. 803. 1. 1/1/ http: //flylib. com/books/en/2. 803. 1. 25/1/22

Document Viewer v The document viewer requests documents by connecting to the server using IPSec v In order for a client to receive a document, it must have access to both the IPSec security association and pass the network access checks for that document at the server v Local SELinux policy was written to close all channels that might be used to release the document beyond the viewer's control v When a revocation is required as a result of a network policy change, the viewer is able to support the revocation of access to the document since it is still within its control v It is important to limit the functionality of the viewer to just viewing documents Computer Security & OS Lab. DKU 23

Network Security Server v Network Security Server n n The network security server implements the network policy over the documents All documents throughout the network, regardless on which document server they reside, must be labeled with a network label v In order for the network security server to be able to make network access decisions, all labels must be translated into a corresponding network label prior to any access check. This translation is done by document servers in the prototype. Computer Security & OS Lab. DKU 24

Policy Changes due to Changing Risk v Policy Change n n n When the perception of risk changes, the system must change its security policy to reflect the new perceived risk How different perceptions of risk are quantified is beyond the scope of this effort, but the prototype demonstrates that given several different security policies for different levels of risk, it is possible to switch between them safely The mechanism that initiates that switch is the risk knob. v In the RAd. AC prototype, the risk knob was implemented as a GUI tool that allows a security administrator to alternate between a collection of predefined security policies Computer Security & OS Lab. DKU 25

Policy Changes due to Changing Risk v When the GUI tool triggers a change n Network policy is reloaded n network security server restricts access to that interface to authorized systems n n n Whenever a policy is loaded, the network security server flushes all the AVCs that are relying on the old policy and calls registered notification routines in the document servers. When a document server receives notification of the policy change, it must ensure all documents for which it is responsible are only viewable in clients authorized to do so under the new policy When a viewer receives a policy change notification, it is responsible for revalidation of all access to all documents being viewed n The viewer does this by requesting access to each document from the server Computer Security & OS Lab. DKU 26

Future Work & Conclusion v Future Work n n The biggest hurdle to overcome in order to mature this technology is to demonstrate how to loosen the restriction imposed on the viewer Net. Top n n Increase functionality in the client flow of data to Net. Top virtual machines can be controlled, and experiments can be done to determine the best way to handle revocation Need automated way of identifying the need to change policy than a manually operated risk knob External sensors to identify changes in the environment will assist in this automation v Conclusion n A network application utilizing the Flask architecture has the ability to enforce a network MAC policy and the flexibility to support changes in policy and revoke previously granted accesses according to policy changes Computer Security & OS Lab. DKU 27

Reference v Wikberg, M. (2007). Secure computing: SELinux. www] http: //www. tml. tkk. fi/Publications/C/25/papers/Wikberg_final. pdf. v http: //debian-handbook. info/browse/stable/sect. selinux. html v http: //www. cse. psu. edu/~tjaeger/cse 543 -f 07/slides/03 -Policy. Concepts. pdf v http: //flylib. com/books/en/2. 803. 1. 1/1/ v http: //flylib. com/books/en/2. 803. 1. 25/1/ Computer Security & OS Lab. DKU 28

Computer Security & OS Lab. DKU 29