A firewall is a system acting as an interface of a network to one or more external networks. It implements the security policy of the network by deciding which packets to let through based on rules defined by the network administrator. Any error in defining the rules may compromise the system security by letting unwanted traffic pass or blocking desired traffic. Manual definition of rules often results in a set that contains conflicting, redundant or overshadowed rules, resulting in anomalies in the policy. Manually detecting and resolving these anomalies is a critical but tedious and error prone task. Existing research on this problem have been focused on the analysis and detection of the anomalies in firewall policy. Previous works define the possible relations between rules and also define anomalies in terms of the relations and present algorithms to detect the anomalies by analyzing the rules. In this paper, we discuss some necessary modifications to the existing definitions of the relations. We present a new algorithm that will simultaneously detect and resolve any anomaly present in the policy rules by necessary reorder and split operations to generate a new anomaly free rule set. We also present proof of correctness of the algorithm. Then we present an algorithm to merge rules where possible in order to reduce the number of rules and hence increase efficiency of the firewall.

N/A

N/A

N/A

N/A

In this article we propose a standard for role-based access control ({RBAC}). Although {RBAC} models have received broad support as a generalized approach to access control, and are well recognized for their many advantages in performing large-scale authorization management, no single authoritative definition of {RBAC} exists today. This lack of a widely accepted model results in uncertainty and confusion about {RBAC}'s utility and meaning. The standard proposed here seeks to resolve this situation by unifying ideas from a base of frequently referenced {RBAC} models, commercial products, and research prototypes. It is intended to serve as a foundation for product development, evaluation, and procurement specification. Although {RBAC} continues to evolve as users, researchers, and vendors gain experience with its application, we feel the features and components proposed in this standard represent a fundamental and stable set of mechanisms that may be enhanced by developers in further meeting the needs of their customers. As such, this document does not attempt to standardize {RBAC} features beyond those that have achieved acceptance in the commercial marketplace and research community, but instead focuses on defining a fundamental and stable set of {RBAC} components. This standard is organized into the {RBAC} Reference Model and the {RBAC} System and Administrative Functional Specification. The reference model defines the scope of features that comprise the standard and provides a consistent vocabulary in support of the specification. The {RBAC} System and Administrative Functional Specification defines functional requirements for administrative operations and queries for the creation, maintenance, and review of {RBAC} sets and relations, as well as for specifying system level functionality in support of session attribute management and an access control decision process.

Historically and by default, Linux does not respect the principle of least privilege because it grants all the privileges to administrators to execute their tasks. With the new personal data protection or export control regulations, the principle of least privilege is mandatory and must be applied even for system administrators. The Linux operating system since version 2.2 divides the privileges associated with the superuser into distinct units called capabilities. Linux capabilities allow coarse-grained access control to restricted system features. The “RootAsRole” project is introduced as a solution for delegating administrative tasks while matching the necessary capabilities. However, limitations in user experience and the mapping of Linux capabilities pose significant obstacles. This paper proposes enhancements to achieving a balance between usability and the principle of least privilege, emphasizing the need for precise capability definitions. Future work involves enhancing the RootAsRole access control model and addressing the need for a comprehensive administration access control framework for managing Linux capabilities effectively.

With the new personal data protection or export control regulations, the principle of least privilege is mandatory and must be applied even for system administrators. This article explores the different approaches implemented by the main operating systems (namely Linux, Windows, FreeBSD, and Solaris) to control the privileges of system administrators in order to enforce the principle of least privilege. We define a set of requirements to manage these privileges properly, striving to balance adherence to the principle of least privilege and usability. We also present a deep analysis of each administrative privilege system based on these requirements and exhibit their benefits and limitations. This evaluation also covers the efficiency of the currently available solutions to assess the difficulty of performing administrative privileges management tasks. Following the results, the article presents the RootAsRole project, which aims to simplify Linux privilege management. We describe the new features introduced by the project and the difficulties we faced. This concrete experience allows us to highlight research challenges.

Today, Linux users use sudo/su commands to attribute Linux's administrative privileges to their programs. These commands always give the whole list of administrative privileges to Linux programs, unless there are pre-installed default policies defined by Linux Security Modules(LSM). LSM modules require users to inject the needed privileges into the memory of the process and to declare the needed privileges in an LSM policy. This approach can work for users who have good knowledge of the syntax of LSM modules’ policies. Adding or editing an existing policy is a very time-consuming process because LSM modules require adding a complete list of traditional permissions as well as administrative privileges. We propose a new Linux module called RootAsRole that is dedicated to the management of administrative privileges. RootAsRole is not proposed to replace LSM modules but to be used as a complementary module to manage Linux administrative privileges. RootAsRole allows Linux administrators to define a set of roles that contain the administrative privileges and restrict their usage to a set of users/groups and programs. Finally, we conduct an empirical performance study to compare RootAsRole tools with sudo/su commands to show that the overhead added by our module remains acceptable.

The typical way to run an administrative task on Linux is to execute it in the context of a super user. This breaks the principle of least privilege on access control. Other solutions, such as SELinux and AppArmor, are available but complex to use. In this paper, a new Linux module, named RootAsRole, is proposed to allow users to fine-grained control the privileges they grant to Linux commands as capabilities. It adopts a role-based access control (RBAC) [14], in which administrators can define a set of roles and the capabilities that are assigned to them. Administrators can then define the rules controlling what roles users or groups can assign to themselves. Each time a Linux user wants to execute a program that necessitates one or more capabilities, (s)he should assign the role to him/herself that contains the needed capabilities, providing there is a rule that allows it. A pilot implementation on Linux systems is illustrated in detail.