Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Seperate allow and deny rules #64

Open
jack-ullery opened this issue Sep 26, 2023 · 1 comment
Open

Seperate allow and deny rules #64

jack-ullery opened this issue Sep 26, 2023 · 1 comment
Labels
enhancement New feature or request

Comments

@jack-ullery
Copy link
Owner

Is your feature request related to a problem? Please describe.
Currently, we show allow rules and deny rules in the same table in the Profile Modify page. This is a problem, because it could potentially confuse users and make them think certain permissions are granted, that are actually prohibited.

Describe the solution you'd like
We could add a column to the beginning of the table, that lists whether the rule is allow or deny. This could be a combobox, which would allow the user to change the rule type easier.

Alternatively, we could separate allow and deny rules into separate tables. This would further distinguish these different types of rules.

The tradeoffs between the two rule types could be: space, adding an extra column would take valuable horizontal space; flexibility, adding an extra table would make it harder to switch rule types and make it impossible to compare allow rules with deny rules.

Additional context
By default, AppArmor File Rules grant access to specific files. These are called allow rules. Optionally, you can prefix "deny" to a rule to prevent access to a resource. These are called deny rules

An example of a deny rule could be: deny /var/log/syslog r.
This would prevent a process from reading the syslog, even if this was allowed by another rule.

@jack-ullery jack-ullery added the enhancement New feature or request label Sep 26, 2023
@jack-ullery
Copy link
Owner Author

This was also mentioned earlier in #56

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant