Working Role manager

.github/workflows/codacy.yml

@@ -15,7 +15,8 @@ name: Codacy Security Scan
 
 on:
   push:
-    branches: [ "main" ]
+    branches: 
+      - '**'
   pull_request:
     # The branches below must be a subset of the branches above
     branches: [ "main" ]

.github/workflows/criterion-test.yml

@@ -2,7 +2,8 @@ name: Criterion Unit Tests
 
 on:
   push:
-    branches: [ main ]
+    branches:
+      - '**'
   pull_request:
     branches: [ main ]
 
@@ -31,5 +32,4 @@ jobs:
       env: 
         CODECOV_TOKEN: ${{ secrets.CODECOV_TOKEN }}
       with:
-        gcov: true
-
+        gcov: true

CHANGELOG.md

@@ -12,7 +12,7 @@ In this Major version, conception of sr tool is redesigned. ancient versions of
 
 In this new version, we focuses on usability and conception of the tool. Because sudo is simpler to use, we redesigned `sr` argument management, which is now minimal, for the happiness of lazy people. RootAsRole is now a more lazy tool than `sudo` because our tool needs only 2 characters, which means 2 times less than `sudo`. We know that `sudo` is used in majority of distributions, so to avoid to change habits, we tried to reproduce the default usage of this tool. We know that sudo provides more functionnalities than our tool. But we think that sudo tries to resolve overloaded amount of needs which became very hard to modify without incidents.
 
-As reminder, `sudo` doesn't respect any security model https://security.stackexchange.com/a/67218. With `sr` we tried to setup a Role based access control model which allows administrator to manage privileges granting in respect of least privilege management. We also know that capabilities tries to respect capability based security model by using similar words. But the design is not respecting this model. Contrary to `sudo`, RootAsRole doesn't permit to user to change his effective identity.
+As reminder, `sudo` doesn't respect any security model <https://security.stackexchange.com/a/67218>. With `sr` we tried to setup a Role based access control model which allows administrator to manage privileges granting in respect of least privilege management. We also know that capabilities tries to respect capability based security model by using similar words. But the design is not respecting this model. Contrary to `sudo`, RootAsRole doesn't permit to user to change his effective identity.
 
 Also, With this new version, many vulnerabilities were fixed.
 
@@ -28,31 +28,28 @@ In next versions, we'll enhance eBPF with new ways of implementation and some ex
 
 With these changes, RootAsRole, has taken initiatives to simplify the deployment of least privilege principle based on process criteria.
 
+## Added on 3.0
 
+- Evironment Variables management
+- Support for Arch Linux
+- setUID and Multiple setGID
+- Partial Order Comparison between roles ! Ghosted roles abolished !
+- Unit-Test with [Criterion Testing Framework](https://github.com/Snaipe/Criterion)
 
-## Added
+## Changed on 3.0
 
- - Evironment Variables management
- - Support for Arch Linux
- - setUID and Multiple setGID
- - Partial Order Comparison between roles ! Ghosted roles abolished !
- - Unit-Test with [Criterion Testing Framework](https://github.com/Snaipe/Criterion)
+- XML Document DTD and conceptual structure
 
-## Changed 
+## Deleted on 3.0
 
- - XML Document DTD and conceptual structure
-
-
-## Deleted
-
- - `sr_aux` program which was useless.
- - old `role-manager` implementation. It wasn't working at all, and source code wasn't reusable.
+- `sr_aux` program which was useless.
+- old `role-manager` implementation. It wasn't working at all, and source code wasn't reusable.
 
 ## [2.2] - 2019-09-27
 
 This version is focused on sr command, no changes in capable command
 
-### Added
+### Added on 2.2
 
 - Improve "-i" option, as user-friendly as possible. Explain every possibilities to specific user. If you don't know if you can, then do "-i"
 
@@ -66,12 +63,12 @@ This version is focused on sr command, no changes in capable command
 
 This version is focused on capable program, no changes on sr command.
 
-### Added
+### Added on 2.1
 
 - New algorithm capabilities detection for capable command, based on namespaces with recursive namespace creation detection. This algorithm will work for almost all cases and is much more optimized than 2.0 algorithm.
 - Beginning of stack trace filtering for capable command, we want to remove the cap_sys_admin capability when _do_fork is in the stack will work only on kernel version 5.X, the program remains retro-compatible for 4.10 version
 
-### Modified
+### Modified on 2.1
 
 - 2.0 algorithm has now the namespace retrieving
 - fix big mistakes on 2.0 algorithm
@@ -84,19 +81,19 @@ This version is focused on capable program, no changes on sr command.
 
 ## [2.0] - 2019-06-04
 
-### Added
+### Added on 2.0
 
 - New Tool called "capable". this tool can be used to resolve capabilities asked by a program, this can be run as daemon, or with command to test.
 - sr is now print which role is used when start
 
-### Changed
+### Changed on 2.0
 
 - option -c is optionnal but it's mandatory to precise the command in the configuration.
 - Fix bugs and memory leaks from testing suite and sr
 
 ## [1.1] - 2019-05-02
 
-### Added
+### Added on 1.1
 
 - Ability to no longer specify a role for the command sr
 - Adding tests for functionality without role
@@ -106,7 +103,7 @@ This version is focused on capable program, no changes on sr command.
 - Added optional parameter -v to get the RAR version
 - Added Changelog file
 
-### Changed
+### Changed on 1.1
 
 - Correction of syntactical faults in the main README
 - Fixed DTD on capabilities (require at least one capability in a role)
@@ -118,7 +115,6 @@ This version is focused on capable program, no changes on sr command.
 - sr command which uses capabilities and xml role system to replace `sudo` or any alternative.
 - initial project
 
-[Unreleased]: https://github.com/SamerW/RootAsRole/compare/V2.2...HEAD
 [2.2]: https://github.com/SamerW/RootAsRole/compare/V2.1...V2.2
 [2.1]: https://github.com/SamerW/RootAsRole/compare/V2.0...V2.1
 [2.0]: https://github.com/SamerW/RootAsRole/compare/V1.1...V2.0

README.md

@@ -1,3 +1,5 @@
+<!-- markdownlint-capture -->
+<!-- markdownlint-disable -->
 <p align="center">
   <img src="./RootAsRolev2.svg" width=75%>
  </p>
@@ -6,25 +8,23 @@
 <img alt="Build Status" src="https://img.shields.io/github/actions/workflow/status/LeChatP/RootAsRole/build.yml?label=Build"/>
 <img alt="Test Status" src="https://img.shields.io/github/actions/workflow/status/LeChatP/RootAsRole/criterion-test.yml?label=Unit%20Tests">
 <a href="https://app.codacy.com/gh/LeChatP/RootAsRole/dashboard?utm_source=gh&utm_medium=referral&utm_content=&utm_campaign=Badge_grade"><img src="https://app.codacy.com/project/badge/Grade/60b8105a12ca4419b8471d150ef93ebd"/></a>
-<a href="https://codecov.io/gh/LeChatP/RootAsRole" > 
- <img src="https://codecov.io/gh/LeChatP/RootAsRole/branch/main/graph/badge.svg?token=6J7CRGEIG8"/> 
+<a href="https://codecov.io/gh/LeChatP/RootAsRole" >
+ <img src="https://codecov.io/gh/LeChatP/RootAsRole/branch/main/graph/badge.svg?token=6J7CRGEIG8"/>
  </a>
  <img alt="GitHub" src="https://img.shields.io/github/license/LeChatP/RootAsRole">
 
 </p>
+<!-- markdownlint-restore -->
 
 # RootAsRole (V3.0-alpha.1) : a secure alternative to sudo/su on Linux systems
 
-
-
-
 A role-based access control tool for administrative tasks on Linux. This tool tries to convince the least privilege and ease of use. We design this tool to being least privilege and least vulnerability prone by default.
 
 ## Installation
 
 ### How to Build
 
-  1. git clone https://github.com/SamerW/RootAsRole
+  1. git clone <https://github.com/SamerW/RootAsRole>
   2. cd RootAsRole
   3. sudo sh ./configure.sh
   4. make
@@ -34,7 +34,7 @@ A role-based access control tool for administrative tasks on Linux. This tool tr
 
 Our role manager is currently under development. But you can manually execute these commands :
 
-```
+```sh
 sr chattr -i /etc/security/rootasrole.xml
 sr nano /etc/security/rootasrole.xml
 ```
@@ -45,7 +45,7 @@ However, today, you can start to configure this tool with the rootasrole.xml fil
 
 ### Usage
 
-```
+```txt
 Usage: sr [options] [command [args]]
 Options:
   -r, --role <role>      Role to use
@@ -62,7 +62,7 @@ You may give us your feedbacks  about RootAsRole here:
 
 ## Video presentation of the version 1.0 (in French)
 
-https://www.youtube.com/watch?v=2Y8hTI912zQ
+<https://www.youtube.com/watch?v=2Y8hTI912zQ>
 
 ## Why do you need this tool ?
 
@@ -72,18 +72,17 @@ RootAsRole module implements a role-based approach for distributing Linux capabi
 
 Our module is compatible with LSM modules (SELinux, AppArmor, etc.) and pam_cap.so. So administrators can continue using pam_cap.so along with our module. Finally, the RootAsRole module includes the capable tool, which helps Linux users know the privileges an application asks for.
 
-
 ## How do we solve Role conflicts ?
 
 As you may know with this RBAC model, it is possible for multiple roles to reference the same command for the same users. Since we do not ask by default the role to use, our tool applies an smart policy to choose a role using user, group, command entry and least privilege criteria. We apply a partial order comparison algorithm to decide which role should be chosen :
 
 * Find all the roles that match the user id assignment or the group id, and the command input
-* Within the matching roles, select the one that is the most precise and least privileged : 
+* Within the matching roles, select the one that is the most precise and least privileged :
    1. user assignment is more precise than the combination of group assignment
    1. the combination of group assignment is more precise than single group assignment
    1. exact command is more precise than command with regex argument
    1. command with regex argument is more precise than a wildcarded command path
-   1.  wildcarded command path is more precise than wildcarded command path and regex args
+   1. wildcarded command path is more precise than wildcarded command path and regex args
    1. wildcarded command path and regex args is more precise than complete wildcard
    1. A role granting no capability is less privileged than one granting at least one capability
    1. A role granting no "ADMIN" capability is less privileged than one granting "ADMIN" capability
@@ -97,17 +96,17 @@ As you may know with this RBAC model, it is possible for multiple roles to refer
    1. A role that enables root privileges is less privileged than one which disables root privileges (see "no-root" feature)
    1. A role that disables the Bounding set feature in RootAsRole is less privileged than one that enables it
 
-
 After these step, if two roles are conflicting, these roles are considered equal (only the environment variables are different), so configurator is being warned that roles could be in conflict and these could not be reached without specifing precisely the role to choose (with `--role` option). In such cases, we highly recommend to review the design of the configured access control.
 
 Regarding the (vii),(viii), and (ix) points, the choice of least privilege is somewhat arbitrary. We are currently working on a explaination on a paper.
 
 ## Tested Platforms
 
 Our module has been tested on:
- * Ubuntu>=16.04
- * Debian>=10
- * ArchLinux
+
+* Ubuntu>=16.04
+* Debian>=10
+* ArchLinux
 
 After the installation you will find a file called rootasrole.xml in the /etc/security directory. You should configure this file in order to define the set of roles and assign them to users or group of users on your system. Once configuration is done, a user can assume a role using the ‘sr’ tool  that is installed with our package.
 
@@ -118,6 +117,7 @@ Since V2.0 of RootAsRole, we created a new tool that permits to retrieve capabil
 For more information please see [Here](https://github.com/SamerW/RootAsRole/tree/master/ebpf)
 
 ## Role Manager
+
 Since V2.3 We created a set of tools that allow to add/edit/delete roles without ncessarily needs to edit XML file manaualy.
 For more information please check here [Here](https://github.com/SamerW/RootAsRole/tree/master/role-manager)
 
@@ -127,17 +127,17 @@ For more information please check here [Here](https://github.com/SamerW/RootAsRo
 
 ## Contributors
 
-Ahmad Samer Wazan : [email protected]
+Ahmad Samer Wazan : <[email protected]>
 
-Rémi Venant: [email protected]
+Rémi Venant: <[email protected]>
 
-Guillaume Daumas : [email protected]
+Guillaume Daumas : <[email protected]>
 
-Eddie Billoir : [email protected]
+Eddie Billoir : <[email protected]>
 
-Anderson Hemlee : [email protected]
+Anderson Hemlee : <[email protected]>
 
-Romain Laborde : [email protected]
+Romain Laborde : <[email protected]>
 
 ## About Logo
 

ebpf/README.md

@@ -3,7 +3,7 @@
 ## Introduction
 
 In many cases, it is very difficult for a user or administrator to know what kind of capabilities are requested by a program. So we build the capable tool in order to help Linux users know discover the capabilities requested by a program. Our tool uses eBPF in order to intercept the cap_capable() calls in the kernel. This filter uses JIT compilation and is injected to the kernel and will give back information to user-space. More details [https://github.com/pratyushanand/learn-bpf](here)
-However, the kernel retruns the list of capabilities to all programs that are running on the OS. We have added a filtering mecanism in order to let the user see only the capabilites requested by his program. 
+However, the kernel retruns the list of capabilities to all programs that are running on the OS. We have added a filtering mecanism in order to let the user see only the capabilites requested by his program.
 
 ## Tested Plateforms
 
@@ -100,18 +100,18 @@ Now we want to get capabilities used to get addresses in kallsyms file :
 ```Txt
 $ capable -c 'cat /proc/kallsyms'
 ...
-0000000000000000 T acpi_video_get_backlight_type	[video]
-0000000000000000 T acpi_video_set_dmi_backlight_type	[video]
-0000000000000000 t acpi_video_detect_exit	[video]
-0000000000000000 T acpi_video_register	[video]
-0000000000000000 T nfnetlink_init	[nfnetlink]
+0000000000000000 T acpi_video_get_backlight_type [video]
+0000000000000000 T acpi_video_set_dmi_backlight_type [video]
+0000000000000000 t acpi_video_detect_exit [video]
+0000000000000000 T acpi_video_register [video]
+0000000000000000 T nfnetlink_init [nfnetlink]
 Here's all capabilities intercepted :
 cap_sys_admin, cap_syslog
 WARNING: These capabilities aren't mandatory, but can change the behavior of tested program.
 WARNING: CAP_SYS_ADMIN is rarely needed and can be very dangerous to grant
 ```
 
-This is an interesting example because the command has not been terminated by the kernel because it doesn't have the necessary capabilities. However, the kernel doesn't deliver the content asked by the command cat because it doesn't have the necessary capabilities. We can see that the command output successfuly without permission denied. But adresses are all in 0. So we shall try to understand what kind of capablities we need. By using capable tool, we figure out that we need cap_sys_admin and cap_sys_log. As we told before, we will not use cap_sys_admin because it is not probably needed, so we will try only with cap_syslog. 
+This is an interesting example because the command has not been terminated by the kernel because it doesn't have the necessary capabilities. However, the kernel doesn't deliver the content asked by the command cat because it doesn't have the necessary capabilities. We can see that the command output successfuly without permission denied. But adresses are all in 0. So we shall try to understand what kind of capablities we need. By using capable tool, we figure out that we need cap_sys_admin and cap_sys_log. As we told before, we will not use cap_sys_admin because it is not probably needed, so we will try only with cap_syslog.
 
 ```Xml
     <role name="stacktrace">
@@ -136,16 +136,16 @@ Authentication of lechatp...
 Password: 
 Privileged bash launched with the role stacktrace and the following capabilities : cap_syslog.
 ...
-ffffffff******** T acpi_video_unregister	[video]
-ffffffff******** T acpi_video_get_backlight_type	[video]
-ffffffff******** T acpi_video_set_dmi_backlight_type	[video]
-ffffffff******** t acpi_video_detect_exit	[video]
-ffffffff******** T acpi_video_register	[video]
-ffffffff******** T nfnetlink_init	[nfnetlink]
+ffffffff******** T acpi_video_unregister [video]
+ffffffff******** T acpi_video_get_backlight_type [video]
+ffffffff******** T acpi_video_set_dmi_backlight_type [video]
+ffffffff******** t acpi_video_detect_exit [video]
+ffffffff******** T acpi_video_register [video]
+ffffffff******** T nfnetlink_init [nfnetlink]
 End of role stacktrace session.
 ```
 
-Perfect! We can see real adresses. 
+Perfect! We can see real adresses.
 
 ## Example 3
 
@@ -233,7 +233,7 @@ As you can see, the daemon has been launched with lechatp user. All of these ste
 
 ## TO-DO
 
-1. Get and read stack trace in kernelside to filter capable() calls by fork() which are non-pertinent for user. This enhancement will ignore CAP_SYS_ADMIN and CAP_SYS_RESOURCES capable() calls for each process. But program must still write entry to map, useful to retrieve the process tree. Note : it seems impossible, see https://www.kernel.org/doc/html/latest/bpf/bpf_design_QA.html#q-can-bpf-programs-access-stack-pointer and see https://www.spinics.net/lists/netdev/msg497159.html but needs confirm. I've read in a commit (I dont resolve him) that bpf_get_stack permits to read stack. Once this found, we will filter capabilities by a "checking" ebpf map. containing list of kallsym ignorable. the ebpf map will lookup in this map for each function trace forwarding 10 iteration max.
+1. Get and read stack trace in kernelside to filter capable() calls by fork() which are non-pertinent for user. This enhancement will ignore CAP_SYS_ADMIN and CAP_SYS_RESOURCES capable() calls for each process. But program must still write entry to map, useful to retrieve the process tree. Note : it seems impossible, see <https://www.kernel.org/doc/html/latest/bpf/bpf_design_QA.html#q-can-bpf-programs-access-stack-pointer> and see <https://www.spinics.net/lists/netdev/msg497159.html> but needs confirm. I've read in a commit (I dont resolve him) that bpf_get_stack permits to read stack. Once this found, we will filter capabilities by a "checking" ebpf map. containing list of kallsym ignorable. the ebpf map will lookup in this map for each function trace forwarding 10 iteration max.
 2. In addition to read stack in TODO#1, We need to sort capabilities to 2 list :
     * mandatory, which corresponds to capabilities who returns -EPERM to program in a specific kernel call
     * optionnal, which corresponds to capabilities who change the behavior of kernel in a specific kernel call

resources/rootasrole.xml

@@ -14,8 +14,7 @@
 	<!ELEMENT roles (role*)>
 	<!ELEMENT role (actors?|task*|options?)*>
 	<!ATTLIST role
-		name ID #REQUIRED
-		priority CDATA "0">
+		name ID #REQUIRED>
 	<!ELEMENT actors (user*|group*)>
 	<!ELEMENT user EMPTY>
 	<!ATTLIST user name CDATA #REQUIRED>

role-manager/Cargo.toml

@@ -19,4 +19,3 @@ tracing-subscriber = "0.3.16"
 cursive = "0.20.0"
 lazy_static = "1.4.0"
 libc = "0.2.139"
-users = "0.11.0"

role-manager/libs/sudoers_reader/grammar/sudoers.pest

@@ -50,9 +50,9 @@ Flag  =  { (CASED_LETTER | "_")+ }
 Host_List   =  { Host | Host ~ "," ~ Host_List }
 Domain_Name = @{ (CASED_LETTER | NUMBER) ~ (CASED_LETTER | NUMBER | "-" | ".")* }
 Host        =  {
-    "!"* ~ Domain_Name
-  | "!"* ~ ip_addr
-  | "!"* ~ netgroup
+    Negate* ~ Domain_Name
+  | Negate* ~ ip_addr
+  | Negate* ~ netgroup
 }
 
 ip_addr   = @{ ip4_addr ~ ("/" ~ netmask4)? | ip6_addr }
@@ -88,7 +88,7 @@ domain_name     = @{ (CASED_LETTER | NUMBER) ~ (CASED_LETTER | NUMBER | "-" | ".
 
 User_List    = _{ User | User ~ "," ~ User_List }
 User         =  {
-    "!"* ~ User_Name
+    Negate* ~ User_Name
 }
 User_Name    = _{ User_Str | id | Group_Name | netgroup }
 Group_Name   = @{ "%" ~ User_Str | "%:" ~ id | "%:" ~ SID_Group | "%" ~ Domain_Group }
@@ -153,6 +153,8 @@ Tag_Spec = {
 
 Include = { "@" ~ (!NEWLINE ~ ANY)* }
 
+Negate = { "!" }
+
 // ### END RULES ###
 // ### COMMENTS ###