Have the parser extract the attachment path from the profile declaration
and make it available as a variable within the profile. This allows
profile rules to use the executable attachment path in rules.
eg.
```
profile ex /bin/** {
@{attach_path} r,
# ...
}
profile /path/to/bin {
@{attach_path} r,
# ...
}
```
if a profile does not define an attachment like
```
profile noattach {
@{attach_path} r,
}
```
the apparmor_parser will fail the compile with the error.
```
Found reference to variable attach_path, but is never declared
```
The attachment xattr/label conditionals are not made available at
this time as regular file path rules can not use them.
Similarly a @{exec_path} variable is made available. It is different
than @{attach_path} in that it is intended to be a kernel variable
that represents the specific executable that was matched at run
time. However to support policy on kernels that don't define the
kernel variable it has a fallback value that is the same as
@{attach_path}.
This patch is a follow on to MR:1637 (https://gitlab.com/apparmor/apparmor/-/merge_requests/1637)
and is similar to how the apparmor.d project uses the manually setup
@{exec_path} variable.
We can bike shed over the variable name. @{attach_path} was chosen
here because this is the attachment conditional path for the
executable, not the executable's actual path. While @{exec_path} is
intended to be the applications actual executable path.
support the @{exec_path} kernel variable (all of them atm).
Notes:
The minimize.sh tests are changed because this patch causes path based
profile names to create an attachment. This could be done by doing the
attach_variable expansion in the alternate location marked by the
patch, but since the kernel is going to start doing this for all
profiles that don't have an attachment it is better for the parser to
do it, as it can optimize better.
This patch may cause breakage if policy declares either @{attach_path}
or @{exec_path} this will not be dealt with here, but in a subsequent
patch that allows variables to have a local scope so that the compiler
defined vars will just get declared locally.
Signed-off-by: John Johansen <john.johansen@canonical.com>
I am unsure how to test this equivalency due to how abi declarations interact with feature file command line arguments, so advice on that would be welcome.
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1585
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
The attach_disconnected.ipc flag allows the use of disconnected paths
on posix mqueues. This flag is a subset of attach_disconnected, and it
does not allow disconnected paths for all files.
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
The documentation was missing information about path sanitization, and
why you shouldn't do a leading @{VAR} on path rules. While the example
doing this was fixed, actual information about why you shouldn't do
this was missing.
Document how apparmor will collapse consecutive / characters into a
single character for paths, except when this occurs at the start of
the path.
Signed-off-by: John Johansen <john.johansen@canonical.com>
As pointed out by https://bugs.launchpad.net/apparmor/+bug/2087875 ,
profile transitions with pivot_root are currently not supported on any
kernel.
This commit makes this limitation more obvious to users.
Signed-off-by: Maxime Bélair <maxime.belair@canonical.com>
The wording of "scrub the environment" with respect to execution modes is misleading, because a quick read of it could imply that it removes all environment variables. However, it actually enables ld.so's secure-execution mode, which removes a very limited subset of them. This MR rewords the relevant documentation and prompts. If proper environment variable filtering is added later, the documentation can be updated again then.
Synchronizes-with:
- Wiki page update, which I can do after this MR is approved
- Kernel patch to update wording of debug logs (patch submitted to the Apparmor mailing list [here](https://lists.ubuntu.com/archives/apparmor/2024-August/013339.html))
Things that may need updating first:
- Translations: attempting to update `utils/po/apparmor-utils.pot` resulted in a bunch of unrelated changes, so I'd like to ask about translation statuses before making a commit that updates that file properly.
- Adding info on which libc's actually behave differently based on AT_SECURE: glibc and musl libc both do, but they may do subtly different things. I don't know about other libc's.
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1315
Approved-by: John Johansen <john@jjmx.net>
Merged-by: Ryan Lee <rlee287@yahoo.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>
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>
inet mediation allows specifying rules for sockets that don't have
a known address, whether because it is unbound or because the
kernel doesn't make the address available.
The current code uses the word anon for anonymous, but that has
proven to be unclear. Switch from using anon to none, to emphasize
that this is a case where there just isn't an address to use as
part of mediation.
Signed-off-by: John Johansen <john.johansen@canonical.com>
- replace example calls of /etc/init.d/apparmor with apparmor.service
- drop /etc/init.d/apparmor in filelist
- replace /var/lib/apparmor/ with /var/cache/apparmor/
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>
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>
SIGNAL makes more sense because it's about a single signal.
Besides that, a9494f55238da46afe84d6fdbcd5ffecfd3b3509 introduced a (at
that point broken) usage of SIGNAL which becomes valid with this commit.
Documentation for io_uring and userns rules is missing from the
apparmor.d man page. Provide some basic documentation for them.
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/349
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>
af_unix allows for sockets to be bound to a name that is autogenerated.
Currently this type of binding is only supported by a very generic
rule.
unix (bind) type=dgram,
but this allows both sockets with specified names and anonymous
sockets. Extend unix rule syntax to support specifying just an
auto bind socket by specifying addr=auto
eg.
unix (bind) addr=auto,
It is important to note that addr=auto only works for the bind
permission as once the socket is bound to an autogenerated address,
the addr with have a valid unique value that can be matched against
with a regular
addr=@name
expression
Fixes: https://bugs.launchpad.net/apparmor/+bug/1867216
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/521
Signed-off-by: John Johansen <john.johansen@canonical.com>
In AppArmor 2 distros could pin the feature file being used by setting
the feature-file option in the config file.
With AppArmor 3 policy is now explicitly tagged with an abi rule.
The problem is the interaction on systems that have a mixture of
AppArmor 2 and AppArmor 3 policy and use feature pinning.
The feature pinning is required to make the apparmor 2 policy behave
as expected but it also overrides the abi rules that are explicitly
set as part of the policy. This means we either have the apparmor 2
pinned policy working as desired or the apparmor 3 policy, but not
both.
To fix this make setting the flag on command line or in config file
lower priority than an abi rule specified in policy. The ability
to override abi rules will be added in a separate patch.
The Priority ordering to determine the policy abi to use is
1. Use abi rules if present
2. if no abi rule use command line option
3. if no abi rule or command line option use config setting
4. if none of the above use the default abi
PR: https://gitlab.com/apparmor/apparmor/-/merge_requests/579
Signed-off-by: John Johansen <john.johansen@canonical.com>
The enforce profile mode is the default but specifying it explicitly
has not been supported. Allow enforce to be specified as a mode. If
no mode is specified the default is still enforce.
The kernel has supported kill and unconfined profile modes for a
long time now. And support to the parser so that profiles can make
use of these modes.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/440
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/7
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Steve Beattie <sbeattie@ubuntu.com>
Add basic support for policy to specify a feature abi. Under the
current implementation the first feature abi specified will be
used as the policy abi for the entire profile.
If no feature abi is defined before rules are processed then the
default policy abi will be used.
If multiple feature abi rules are encountered and the specified
abi is different then a warning will be issued, and the initial abi
will continue to be used. The ability to support multiple policy
feature abis during a compile will be added in a future patch.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/491
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Steve Beattie <sbeattie@ubuntu.com>
Documentation of the profile header: name, attachments and flags
is missing. Add basic documentation describing the header and
it components.
PR: https://gitlab.com/apparmor/apparmor/-/merge_requests/505
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Steve Beattie <steve.beattie@canonical.com>
Update the language description to provide some over arching
principles, such as the policy is declarative.
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Christian Boltz <apparmor@cboltz.de>
Acked-by: Steve Beattie <steve.beattie@canonical.com>
The apparmor.d manpage listed 'to' as an alternative for '->' in link
rules.
However, the parser doesn't accept 'to', none of our examples and tests
include it, and nobody ever complained about it. Therefore I'll call
this a documentation bug ;-) and simply adjust the manpage to only list
'->' as valid syntax.
Add userland support for matching based on extended file attributes. This
leverages DFA based matching already in the kernel:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8e51f908https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=73f488cd
Matching is exposed via flags on the profile:
/usr/bin/* xattrs=(user.foo=bar user.bar=foo) {
# ...
}
xattr values are appended to the existing xmatch via a null transition.
$ echo '/usr/bin/* xattrs=(user.foo=foo user.bar=bar) {}' | \
./parser/apparmor_parser -QT -D expr-tree
DFA: Expression Tree
/usr/bin/[^\0000/]([^\0000/])*(\0000bar)?(\0000foo)?< 0x1>
DFA: Expression Tree
(\a|(\n|(\0002|\t)))< 0x4>
Tested manually on a 4.19 kernel via QEMU+KVM.
TODO:
* ~~Add regression tests~~ (EDIT: done)
* ~~EDIT: add support in the tools~~ (EDIT: done)
Questions for reviewers:
* ~~parser/libapparmor: regex construction probably needs cleaning up~~ (EDIT: done)
* ~~parser/parser_regex.c: confused what xmatch length is for~~ (EDIT: done)
/cc @mjg59
PR: https://gitlab.com/apparmor/apparmor/merge_requests/270
Signed-off-by: John Johansen <john.johansen@canonical.com>
