The tools don't support having multiple options specified in mount
rules as it is allowed in the parser.
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
Make it so the @{exec_path} and @{attach_path} variables behavior
completely as local variables, overriding global variables of the
same name, instead of conflicting with them.
The exec var is only validate for the profile block after the attachment
is defined so the pattern
@{exec_path}=/path
profile test @{exec_path} {
@{exec_path} rw,
}
is valid with the global var defining the attachent which then sets
the local auto @{exec_path} and @{attach_path} variables.
Signed-off-by: John Johansen <john.johansen@canonical.com>
- the autovars not being defined because the profile doesn't have an
attachment
- the autovar conflicting with a user defined var of the same name
Signed-off-by: John Johansen <john.johansen@canonical.com>
Add basic support for the priority rules prefix. This patch does not
allow the utils to set or suggest priorities. It allows parsing and
retaining of the priority prefix if it already exists on rules and
checking if it's in the supported range.
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
Signed-off-by: John Johansen <john.johansen@canonical.com>
This enables us to exercise the front perms parse logic in the utils rule parsing through the simple tests as well
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
... and adjust the tools to raise an exception if such a rule is found.
While this is not nice, it's better than the previous behaviour where
only the last 'fstype' was kept, and the others were lost when writing
the rule.
... and adjust the tools to raise an exception if such a rule is found.
While this is not nice, it's better than the previous behaviour where
only the last 'options' was kept, and the others were lost when writing
the rule.
Note: If multiple fstype= or options= are given, this is not detected as
an error (to keep the regex simpler). When writing back such a rule,
only one fstype and options will "survive".
Adjust the exclude list in test-parser-simple-tests.py accordingly:
- several valid mount rules no longer fail
- two invalid mount rules which so far accidentally raised an exception
because of the fstype/options order no longer raise this exception
(conflicting mount options, which are the real reason why these rules
are invalid, are not detected in the tools)
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/501
The tools are wrong in parsing the detached mount test.
Until that can be fixed, mark the tools as wrong.
Signed-off-by: John Johansen <john.johansen@canonical.com>
Fixes https://bugs.launchpad.net/apparmor/+bug/2106033
Improve the validation of AARE file paths by introducing a new regex
that supports paths starting with '{' (e.g. '{/,/org/freedesktop/DBus}').
These paths are notably used in snap.lxd.* profiles.
Signed-off-by: Maxime Bélair <maxime.belair@canonical.com>
This fixes an error with Python 3.11:
```
test/test-parser-simple-tests.py:420:21: E502 the backslash is redundant between brackets
```
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
This enables adding a priority to a rules in policy, finishing out the
priority work done to plumb priority support through the internals in
the previous patch.
Rules have a default priority of 0. The priority prefix can be added
before the other currently support rule prefixes, ie.
[priority prefix][audit qualifier][rule mode][owner]
If present a numerical priority can be assigned to the rule, where the
greater the number the higher the priority. Eg.
priority=1 audit file r /etc/passwd,
priority=-1 deny file w /etc/**,
Rule priority allows the rule with the highest priority to completely
override lower priority rules where they overlap. Within a given
priority level rules will accumulate in standard apparmor fashion.
Eg. given
priority=1 w /*c,
priority=0 r /a*,
priority=-1 k /*b*,
/abc, /bc, /ac .. will have permissions of w
/ab, /abb, /aaa, .. will have permissions of r
/b, /bcb, /bab, .. will have permissions of k
User specified rule priorities are currently capped at the arbitrary
values of 1000, and -1000.
Notes:
* not all rule types support the priority prefix. Rukes like
- network
- capability
- rlimits need to be reworked
need to be reworked to properly preserve the policy rule structure.
* this patch does not support priority on rule blocks
* this patch does not support using a variable in the priority value.
Signed-off-by: John Johansen <john.johansen@canonical.com>
Mount Rules with options in { remount, [make-] { [r]unbindable, [r]shared, [r]private, and [r]slave }} do not support specifying a source. This commit aligns utils implementation to apparmor_parser's, which prohibits having a both source and a destination simultaneously, instad of just prohibiting source.
Therefore, both `mount options=(unbindable) /a,` and `mount options=(unbindable) -> /a,` are now supported (and equivalent for apparmor_parser). However, `mount options=(unbindable) /a -> /b,` is invalid.
For the same reason, specifying a fstype in these cases is also prohibited.
Similarly, we prohibit to specify a fstype for bind mount rules.
Fixes: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2065685
Signed-off-by: Maxime Bélair <maxime.belair@canonical.com>
Add a flag that allows setting the error code AppArmor will send when
an operation is denied. This should not be used normally.
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
- Before this commit, fstype had to match a known fs. However, having and maintaining the exhaustive list of fstypes proved challenging (see !1195 and !1176). Therefore, we add support for any filesystem name.
- Completing AARE support for fstype (brace expressions like ext{3,4} are now supported).
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1198
Approved-by: Christian Boltz <apparmor@cboltz.de>
Merged-by: Christian Boltz <apparmor@cboltz.de>
- Before this commit, fstype had to match a known fs. However, having and maintaining the exhaustive list of fstypes proved challenging (see !1195 and !1176). Therefore, we add support for any filesystem name.
- Completing AARE support for fstype (brace expressions like ext{3,4} are now supported).
... now that the previous commits fixed issues that ended up as unknown
keywords.
Also add mount/ok_12.sd as known-failing test. It uses fstype=AARE which
MountRule doesn't support (yet?).
... based on /mount.cc mnt_opts_table
Several keywords and aliases were missing in flags_keywords:
- B
- M
- make-private
- make-rprivate
- make-rshared
- make-rslave
- make-runbindable
- make-shared
- make-slave
- make-unbindable
- r
- R
- read-only
- w
Also sort the keywords in the same order as in mount.cc.
Note: AARE handling is still a TODO.
After that, update the list of known parsing failures:
- several valid profiles are now correctly parsed
- some `"make-*" mount opt and an invalid src` bad profiles are no
longer detected as being invalid
Add support for a default_allow mode that facillitates writing profiles
in that allow everything by default. This is not normally recomended
but fascilitates creating basic profiles while working to transition
policy away from unconfined.
This mode is being added specifically to replace the use of the
unconfined flag in these transitional profiles as the use of unconfined
in policy is confusing and does not reflect the semantics of what is
being done.
Generally the goal for policy should be to remove all default_allow
profiles once the policy is fully developed.
Note: this patch only adds parsing of default_allow mode. Currently
it sets the unconfined flag to achieve default allow but this
prevents deny rules from being applied. Once dominance is fixed a
subsequent patch will transition default_allow away from using
the unconfined flag.
Signed-off-by: John Johansen <john.johansen@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1109
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
Add support for a default_allow mode that facillitates writing profiles
in that allow everything by default. This is not normally recomended
but fascilitates creating basic profiles while working to transition
policy away from unconfined.
This mode is being added specifically to replace the use of the
unconfined flag in these transitional profiles as the use of unconfined
in policy is confusing and does not reflect the semantics of what is
being done.
Generally the goal for policy should be to remove all default_allow
profiles once the policy is fully developed.
Note: this patch only adds parsing of default_allow mode. Currently
it sets the unconfined flag to achieve default allow but this
prevents deny rules from being applied. Once dominance is fixed a
subsequent patch will transition default_allow away from using
the unconfined flag.
Signed-off-by: John Johansen <john.johansen@canonical.com>
... and error out if an unknown capability is given.
This also means recognizing bad capabilities in the parser simple_tests
now works (so remove these from the exception_not_raised list), and that
we can no longer hand over an unknown capability in test-capability.py
to test their severity.
Extend the policy syntax to have a rule that allows specifying all
permissions for all rule types.
allow all,
This is useful for making blacklist based policy, but can also be
useful when combined with other rule prefixes, eg. to add audit
to all rules.
audit access all,
Signed-off-by: John Johansen <john.johansen@canonical.com>
Add a flag that allows setting the signal used to kill the process.
This should not be normally used but can be very useful when
debugging applications, interaction with apparmor.
Signed-off-by: John Johansen <john.johansen@canonical.com>
Add support for specifying the path prefix used when attach disconnected
is specified. The kernel supports prepending a different value than
/ when a path is disconnected. Expose through a profile flag.
Signed-off-by: John Johansen <john.johansen@canonical.com>
Allowing access to a debug flag can greatly improve policy debugging.
This is different than the debug mode of old, that was removed. It only
will trigger additional messages to the kernel ring buffer, not
the audit log, and it does not change mediation.
Signed-off-by: John Johansen <john.johansen@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1048
made it so rules like
mount slave /snap/bin/** -> /**,
mount /snap/bin/** -> /**,
would get passed into change_mount_type rule generation when they
shouldn't have been. This would result in two different errors.
1. If kernel mount flags were present on the rule. The error would
be caught causing an error to be returned, causing profile compilation
to fail.
2. If the rule did not contain explicit flags then rule would generate
change_mount_type permissions based on souly the mount point. And
the implied set of flags. However this is incorrect as it should
not generate change_mount permissions for this type of rule. Not
only does it ignore the source/device type condition but it
generates permissions that were never intended.
When used in combination with a deny prefix this overly broad
rule can result in almost all mount rules being denied, as the
denial takes priority over the allow mount rules.
Fixes: https://bugs.launchpad.net/apparmor/+bug/2023814
Fixes: https://bugzilla.opensuse.org/show_bug.cgi?id=1211989
Fixes: 9d3f8c6cc ("parser: fix parsing of source as mount point for propagation type flags")
Fixes: MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1048
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1054
Signed-off-by: John Johansen <john.johansen@canonical.com>
(cherry picked from commit 86d193e183bf71448e2394734b0f2d8c316bb262)
Signed-off-by: John Johansen <john.johansen@canonical.com>
These tests contains incompatible mount options and broken
after ("parser: add conflicting flags check for options= conditionals")
Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
Acked-by: John Johansen <john.johansen@canonical.com>
