Skip to main content
SpringerLink
Log in

The functionality-based application confinement model

  • Regular Contribution
  • Published:
International Journal of Information Security Aims and scope Submit manuscript

Abstract

This paper presents the functionality-based application confinement (FBAC) access control model. FBAC is an application-oriented access control model, intended to restrict processes to the behaviour that is authorised by end users, administrators, and processes, in order to limit the damage that can be caused by malicious code, due to software vulnerabilities or malware. FBAC is unique in its ability to limit applications to finely grained access control rules based on high-level easy-to-understand reusable policy abstractions, its ability to simultaneously enforce application-oriented security goals of administrators, programs, and end users, its ability to perform dynamic activation and deactivation of logically grouped portions of a process’s authority, its approach to process invocation history and intersection-based privilege propagation, its suitability to policy automation techniques, and in the resulting usability benefits. Central to the model are ‘functionalities’, hierarchical and parameterised policy abstractions, which can represent features that applications provide; ‘confinements’, which can model simultaneous enforcement of multiple sets of policies to enforce a diverse range of types of application restrictions; and ‘applications’, which represent the processes to be confined. The paper defines the model in terms of structure (which is described in five components) and function, and serves as a culmination of our work thus far, reviewing the evaluation of the model that has been conducted to date.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Log in via an institution

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

Fig. 1
Fig. 2
Fig. 3
Fig. 4
Fig. 5
Fig. 6
Fig. 7
Fig. 8
Fig. 9
Fig. 10
Fig. 11
Fig. 12
Fig. 13

Similar content being viewed by others

Notes

  1. Note that the same result can be achieved without deviating from the FBAC model, by creating non-reusable, application-specific functionalities. This was avoided during the study, since the study aimed to analyse the reusability of the FBAC policy abstractions.

  2. For further details regarding the methods, results, and discussion please refer to this publication. An overview is presented here as part of the wider evaluation of the FBAC model.

References

  1. Yee, B., Sehr, D., Dardyk, G., Chen, J.B., Muth, R., Ormandy, T., Okasaka, S., Narula, N., Fullagar, N.: Native client: a sandbox for portable, utrusted x86 native code. Commun. ACM 53(1), 91–99 (2010)

    Article  Google Scholar 

  2. Gong, L., Mueller, M., Prafullchandra, H., Schemers, R.: Going beyond the sandbox: an overview of the new security architecture in the Java development kit 1.2. In: Proceedings of the USENIX Symposium on Internet Technologies and Systems, Monterey, CA, USA. Prentice Hall PTR (1997)

  3. Whitaker, A., Shaw, M., Gribble, S.D.: Denali: lightweight virtual machines for distributed and networked applications. In: Proceedings of the 5th USENIX Symposium on Operating Systems Design and Implementation, Boston, MA, USA. USENIX Association (2002)

  4. Madnick, S.E., Donovan, J.J.: Application and analysis of the virtual machine approach to information security. In: ACM Workshop on Virtual Computer Systems, Cambridge, MA, USA. Harvard University (1973)

  5. Kamp, P.-H., Watson, R.: Jails: confining the omnipotent root. In: Proceedings of the 2nd International System Administration and Networking Conference (SANE 2000), Maastricht, The Netherlands (2000)

  6. Tucker, A., Comay, D.: Solaris zones: operating system support for server consolidation. In: Proceedings of the 3rd Virtual Machine Research and Technology Symposium Works-in-Progress, San Jose, CA, USA (2004)

  7. Boebert, W.E., Kain, R.Y.: A practical alternative to hierarchical integrity policies. In: Proceedings of the 8th National Computer Security Conference, Gaithersburg, MD, USA. NIST (1985)

  8. Goldberg, I., Wagner, D., Thomas, R., Brewer, E.A.: A secure environment for untrusted helper applications: confining the Wily Hacker. In: Proceedings of the 6th USENIX Security Symposium, San Jose, CA, USA. USENIX Association (1996)

  9. Provos, N.: Improving host security with system call policies. In: Proceedings of the 12th USENIX Security Symposium, Washington, DC, USA, USENIX Association, Aug 2002

  10. Cowan, C., Beattie, S., Kroah-Hartman, G., Pu, C., Wagle, P., Gligor, V.: SubDomain: parsimonious server security. In: Proceedings of the USENIX 14th Systems Administration Conference, New Orleans, LA, USA. USENIX Association (2000)

  11. Loscocco, P., Smalley, S.: Integrating flexible support for security policies into the Linux operating system. In: Proceedings of the FREENIX Track: 2001 USENIX Annual Technical Conference, Boston, MA, USA. USENIX Association (2001)

  12. Harada, T., Horie, T., Tanaka, K.: Task oriented management obviates your onus on Linux. In: Proceedings of the Linux Conference, Tokyo, Japan (2004)

  13. Sandhu, R., Ferraiolo, D., Kuhn, R.: Role based access control. American National Standards Institute/International Committee for Information Technology Standards (ANSI/INCITS) (2004)

  14. Walker, K., Sterne, D., Badger, M., Petkac, M., Sherman, D., Oostendorp, K.: Confining root programs with domain and type enforcement. In: Proceedings of the 6th USENIX Security Symposium, San Jose, CA, USA, USENIX Association (1996)

  15. Schreuders, Z.C.: A role-based approach to restricting application execution.Thesis, Murdoch University (2005)

  16. Raje, M.: TRCS 99-12: Behavior-Based Confinement of Untrusted Applications. University of California, Oakland, CA (1999)

  17. Acharya, A., Raje, M.: MAPbox: using parameterized behavior classes to confine applications. In: Proceedings of the 9th USENIX Security Symposium, Denver, CO, USA. USENIX Association (2000)

  18. Giuri, L., Iglio, P.: Role templates for content-based access control. In: Proceedings of the 2nd ACM Workshop on Role-Based Access Control, Fairfax, VA, USA. ACM Press (1997)

  19. Yao, W., Moody, K., Bacon, J.: A model of OASIS role-based access control and its support for active security. In: 1997 6th ACM Symposium on Access Control Models and Technologies, Chantilly, VA, USA. ACM Press (2001)

  20. Ferraiolo, D., Cugini, J.A., Kuhn, R.: Role-based access control (RBAC): features and motivations. In: Proceedings of the 11th Annual Computer Security Applications Conference (ACSAC), Gaithersburg, MD, USA. IEEE Computer Society Press (1995)

  21. Johnson, M., Karat, J., Karat, C.-M., Grueneberg, K.: Optimizing a policy authoring framework for security and privacy policies. In: Proceedings of the 6th Symposium on Usable Privacy and Security (SOUPS), Redmond, Washington, DC, USA. ACM Press (2010)

  22. Wagner, D.A.: Janus: an approach for confinement of untrusted applications. M.S. thesis. Electrical Engineering and Computer Sciences. University of California, Berkeley, CA (1999)

  23. Berman, A., Bourassa, V., Selberg, E.: TRON: process-specific file protection for the UNIX operating system. In: Proceedings of the Winter USENIX Conference, New Orleans, LA, USA. USENIX Association (1995)

  24. Hallyn, S.E., Kearns, P.: Domain and type enforcement for Linux. In: Proceedings of the 4th Annual Linux Showcase and Conference, Atlanta, GA, USA (2000)

  25. Zanin, G., Mancini, L.V.: Towards a formal model for security policies specification and validation in the SELinux system. In: Proceedings of the 9th ACM Symposium on Access Control Models and Technologies, Yorktown Heights, NY, USA. ACM Press (2004)

  26. Hallyn, S.E., Morgan, A.G.: Linux capabilities: making them work. In: Proceedings of the Linux Symposium, Ottawa, ON, Canada (2008)

  27. Edge, C., Barker, W., Hunter, B., Sullivan, G.: Enterprise Mac Security: Mac OS X Snow Leopard, 2nd edn. Apress, New York (2010)

  28. Ferraiolo, D.F., Sandhu, R., Gavrila, S., Kuhn, D.R., Chandramouli, R.: Proposed NIST standard for role-based access control. ACM Trans. Inf. Syst. Secur. (TISSEC) 4(3), 224–274 (2001)

    Article  Google Scholar 

  29. Tidswell, J., Potter, J.: An approach to dynamic domain and type enforcement. In: Proceedings of the Australasian Conference on Information Security and Privacy, Syndey, NSW, Australia. Springer (1997)

  30. Ott, A.: The role compatibility security model. In: Proceedings of the 7th Nordic Workshop on Secure IT Systems (NordSec), Karlstad, Sweden (2002)

  31. Hinrichs, S., Naldurg, P.: Attack-based domain transition analysis. In: Proceedings of the 2nd Annual Security Enhanced Linux Symposium, Baltimore, MD, USA (2006)

  32. Hardy, N.: The confused deputy: or why capabilities might have been invented. ACM SIGOPS Oper. Syst. Rev. 22(4), 36–38 (1988)

  33. Fournet, C., Gordon, A.D.: Stack inspection: theory and variants. ACM Trans. Program. Lang. Syst. (TOPLAS) 25(3), 360–399 (2003)

    Article  Google Scholar 

  34. Wallach, D.S., Felten, E.W.: Understanding Java stack inspection. In: Proceedings of the 19th IEEE Symposium on Security and Privacy, Oakland, CA, USA. IEEE Computer Society (1998)

  35. Besson, F., Blanc, T., Fournet, C., Gordon, A.D.: From stack inspection to access control: a security analysis for libraries. In: Proceedings of the 17th IEEE Computer Security Foundations Workshop, Asilomar, CA, USA IEEE Computer Society (2004)

  36. Hunt, G., Larus, J., Abadi, M., Aiken, M., Barham, P., Fhndrich, M., Hawblitzel, C., Hodson, O., Levi, S., Murphy, N., Steensgaard, B., Tarditi, D., Wobber, T., Zill, B.: An overview of the singularity project. Microsoft Research, Redmond, WA, USA (2005)

  37. Schreuders, Z.C.: The functionality-based application confinement model and its Linux prototype FBAC-LSM (presentation). In: linux.conf.au—LCA2009, Tasmania, Australia (2009)

  38. Schreuders, Z.C.: FBAC-LSM: protect yourself from your apps. http://schreuders.org/FBAC-LSM (accessed 2011)

  39. Harada, T., Horie, T., Tanaka, K.: Towards a manageable Linux security. In: Proceedings of the Linux conference 2005 (Japanese), Japan (2005)

  40. Morris, J.: Filesystem labeling in SELinux. Linux J. 126, 22–24 (2004)

    Google Scholar 

  41. Schaufler, C.: The simplified mandatory access control kernel. http://schaufler-ca.com/ (2008)

  42. Department of Defense: Trusted computer security evaluation criteria. DOD 5200.28-STD (1985)

  43. Boebert, W.E., Kain, R.Y.: A practical alternative to hierarchical integrity policies. In: Proceedings of the 8th National Computer Security Conference, pp. 18–27 (1985)

  44. Schreuders, Z.C., Payne, C.: Reusability of functionality-based application confinement policy abstractions. In: Proceedings of the 10th International Conference on Information and Communications Security (ICICS 2008), Birmingham, UK. Springer (2008)

  45. Schreuders, Z.C., Payne, C., McGill, T.: A Policy language for abstraction and automation in application-oriented access controls: the functionality-based application confinement policy language. In: Proceedings of the IEEE International Symposium on Policies for Distributed Systems and Networks (POLICY 2011), Italy, Pisa. IEEE Computer Society (2011)

  46. Schreuders, Z.C., Payne, C., McGill, T.: Techniques for automating policy specification for application-oriented access controls. In: Proceedings of the 6th International Conference on Availability, Reliability and Security (ARES 2011), Vienna, Austria. IEEE Computer Society (2011)

  47. Schreuders, Z.C., McGill, T., Payne, C.: Towards usable application-oriented access controls: qualitative results from a usability study of SELinux, AppArmor and FBAC-LSM. Int. J. Inf. Secur. Priv. 6(1), 57–76 (2012)

    Article  Google Scholar 

  48. Schreuders, Z.C., McGill, T., Payne, C.: Empowering end users to confine their own applications: the results of a usability study comparing SELinux, AppArmor and FBAC-LSM. ACM Trans. Inf. Syst. Secur. (TISSEC) 14(2), 1–28 (2011)

    Article  Google Scholar 

Download references

Author information

Authors and Affiliations

  1. School of Computing, Creative Technologies and Engineering, Leeds Metropolitan University, Caedmon Hall, Headingley Campus, Leeds, West Yorkshire, LS6 3QS, UK

    Z. Cliffe Schreuders

  2. School of Information Technology, Murdoch University, Murdoch, WA, 6150, Australia

    Christian Payne & Tanya McGill

Authors
  1. Z. Cliffe Schreuders
    View author publications

    You can also search for this author in PubMed Google Scholar

  2. Christian Payne
    View author publications

    You can also search for this author in PubMed Google Scholar

  3. Tanya McGill
    View author publications

    You can also search for this author in PubMed Google Scholar

Corresponding author

Correspondence to Z. Cliffe Schreuders.

Appendix: Model logic

Appendix: Model logic

This paper has introduced FBAC, defined its components and the model structure, discussed the design of privilege propagation across process invocation, and presented evaluation of the model. This appendix defines the logic that is utilised to enforce the FBAC model. Algorithms are presented here for starting new processes, performing access decisions, and resolving parameters to values. The specification of these algorithms is necessarily complex; however, each algorithm is also described in less formal terms.

The names of the functions used to identify mapped entities in the following algorithms are displayed on the entity mapping connections in Fig. 14. For example, PT(PROCESS x) represents the set of task confinements associated with the process denoted by the variable ‘x’. This notation can denote the association in either direction: for example, PT(TASK_CONFINEMENT c) represents the process associated with the task confinement ‘c’. Attribute values (as shown in Fig. 14 as dotted rectangles) are accessed using a ‘.’ followed by the entity name: for example, task_confinement.propagate. It is suggested the reader refers to the figure while reading the following sections.

Fig. 14
figure 14

The FBAC model, showing set association function names

Full size image

1.1 Starting a process

The procedure for starting a new process involves checking that the program is authorised to run, creating the process context and policy instances, and managing the ancestry propagation of authority. The procedure is divided into functions, and each function is first described then defined using pseudocode.

As defined in Fig. 15, the function process_start describes how processes start. The function parent_task_conf is called to retrieve each task confinement from the parent, which is added to the ancestry association for the child process. The function find_propagation_type is then used to retrieve the execute operation that authorises the parent to start the new process. If, for any of the task confinements, the parent is not authorised to start the new process, the attempt is denied and the process will not start. If the process has no parent (that is, the parent is unconfined or non-existent), then the child starts using the execute_load_profile operation. This means that ancestry for that process will not be considered again when making access decisions.

Fig. 15
figure 15

Function process_start

Full size image

The application that applies to the process is identified based on the executable path using the find_application function. If no policy is found for the process, the confinement attribute no_profile (which can be configured by an administrator, and was described in Sect. 2.4) is used to decide whether to restrict the process to a limited policy, confine it using its parent’s policy (unconfined if the parent was unconfined), or deny the execution. If the program is permitted to run, the function manage_propagation is then called to modify the process ancestry (if required due to a parent running with the execute_shell operation).

The remaining functions described in this section perform other steps necessary for process_start to function. The process ancestry is maintained separately for each task confinement, since each confinement can represent separate rules. Therefore, a process can have a different ancestry of rules that needs to be considered for each task confinement. The function parent_task_conf, shown in Fig. 16, simply retrieves and returns the parent task confinement for a given task confinement, by searching for one that is associated with the parent process and is inherited from the same confinement.

Fig. 16
figure 16

Function parent_task_conf

Full size image

The function find_propagation_type, shown in Fig. 17, queries a task confinement for the authority to start a program. If no privilege allows the program to run, the function returns NONE, and process_start stops the process from starting. Otherwise, the operation used to authorise the process to start is returned. As shown in the algorithm below, the operations are checked in the following order of precedence: execute_as_current_app, execute_as_interpreted, execute_shell, execute_load_profile, then execute. The function conf_has_authority (as defined later in the access control decision logic) is used to check whether starting the program with one of these operations is authorised. If the parent was started using execute_shell or execute_as_current_app, then the confinement’s parent’s privileges are queried (i.e. the parent’s parent, and so on recursively).

Fig. 17
figure 17

Function find_propagation_type

Full size image

The find_application function, shown in Fig. 18, simply searches all the application in a confinement, for an application that has an executable matching the executable_path argument.

Fig. 18
figure 18

Function find_application

Full size image

The function build_task_tree, shown in Fig. 19, creates the new records and establishes the relationships between records to represent the presence of a new process on the system. As shown in the algorithm, the new process is first associated with the user entity. A new task confinement is created as an instance of the confinement and is associated with the process. The application is associated with the new task confinement. All the functionalities associated with the application (and recursively all contained functionalities) are created as functionality instances and associated with the new process.

Fig. 19
figure 19

Function build_task_tree

Full size image

The function create_func_instance_recursive, shown in Fig. 20, is called by build_task_tree and simply creates and establishes the relationships between contained functionality instances.

Fig. 20
figure 20

Function create_func_instance_recursive

Full size image

After everything else has successfully been established, the function manage_propagation, shown in Fig. 21, is called by process_start to set the propagation type of the new process. If the parent confinement was running as execute_shell and the operation used to authorise the process to start was execute_load_profile, then the operation is reset to execute (so that the shell can be used to launch helper programs, as described in Sect. 3). The operation that has been calculated is associated with the task confinement.

Fig. 21
figure 21

Function manage_propagation

Full size image

1.2 Access decision

The logic used to make access control decisions is defined in this section. The function task_has_privilege, shown in Fig. 22, is the interface to the decision logic. It reports whether a process is authorised to perform an action, given the operation and the specifics of the resources to be accessed (specified via the ‘arguments’ function parameter). As shown in the algorithm, task_has_privilege uses the conf_has_authority function to check that every task confinement for a process authorises the proposed access. This enforces the requirement that the resulting permission is an intersection of these confinements.

Fig. 22
figure 22

Function task_has_privilege

Full size image

The function conf_has_authority, shown in Fig. 23, returns whether a given task confinement authorises the action. This function takes the type of propagation into account. Depending on the type of propagation, it may call itself recursively for its parent and may check the privileges associated with the task confinement using the test_all_app_privileges_with_op function. If there is no task confinement supplied (that is, there is no parent task confinement), the recursive call returns TRUE, and the intersection of the previous task confinements is returned. This enforces the requirement that the authority granted by a task confinement is an intersection of the hierarchy of task confinements for the process’s ancestry.

Fig. 23
figure 23

Function conf_has_authority

Full size image

The function test_all_app_privileges_with_op, shown in Fig. 24, is used by conf_has_authority to check whether an application for a specific task confinement grants the authority to perform an action. This is achieved by calling the function test_all_func_privileges_with_op to check whether any of the functionality instances associated with a task confinement’s application authorise the activity. Subsequently test_all_func_privileges_with_op, shown in Fig. 25, recursively calls itself to check whether any functionality instances contained within the functionality grant the access. For every functionality, test_direct_privs is used to test the privileges directly assigned to each functionality.

Fig. 24
figure 24

Function test_all_app_privileges_with_op

Full size image
Fig. 25
figure 25

Function test_all_func_privileges_with_op

Full size image

The function test_direct_privs, shown in Fig. 26, searches for privileges matching the specified operation and calls test_permission to test if that privilege grants access.

Fig. 26
figure 26

Function test_direct_privs

Full size image

The function test_permission, shown in Fig. 27, calls the implementation-dependent has_privilege to check whether the arguments supplied to the decision logic are a match for any resource descriptors associated with the privilege. This can involve different types of comparisons based on the type of resource being accessed. As previously discussed in Sect. 2, this may involve pattern matching between the patterns specified in resource descriptors and the strings representing the resource in the parameter arguments. Resolving parameters, as described in the next section, can be used at this stage to determine non-literal parameter argument values.

Fig. 27
figure 27

Function test_permission

Full size image

1.2.1 Resolving parameter arguments to privileges

As previously discussed in Sect. 2.3, application policies or functionalities can supply literal arguments (in other words, actual descriptions of resources) to parameters. These associations are represented in Fig. 14 as AA and FA. However, parameters can also refer to other parameters contained in parent functionalities. This is represented as PP in the figure. It is necessary to resolve these parameters to literal arguments in order to make access decisions.

The algorithm presented in this section resolves resource descriptors that refer to parameters to the literal argument values that describe the resources the operation grants access to.

The function resolve_nonliteral_resource_descriptor, shown in Fig. 28, returns a literal result that describes resources. If the ‘resource_descr’ argument is already literal (that is, it is not associated with a parameter), it is simply returned. If it is non-literal (it is associated with a parameter), then the function resolve_argument is used to return the literal parameter argument.

Fig. 28
figure 28

Function resolve_nonliteral_resource_descriptor

Full size image

The function resolve_argument, shown in Fig. 29, checks whether a parameter is associated with a parent parameter. If it is, the function calls itself recursively until all parents have been traversed and a literal value is found. If the parameter has no parent parameters, then the corresponding literal argument is returned.

Fig. 29
figure 29

Function resolve_argument

Full size image

Rights and permissions

Reprints and permissions

About this article

Cite this article

Schreuders, Z.C., Payne, C. & McGill, T. The functionality-based application confinement model. Int. J. Inf. Secur. 12, 393–422 (2013). https://doi.org/10.1007/s10207-013-0199-4

Download citation

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s10207-013-0199-4

Keywords

Search

Navigation