Snap policy is a special case of the unknown profile. Give the user
a slightly better message for these messages.
Signed-off-by: John Johansen <john.johansen@canonical.com>
The current notification can be confusing, in that it can present a
profile followed by a list of rules that can't be selected.
Explictly state that the Unknown profile can't be modified so the user
has some indication that not being able to select the shown rules is
expected.
Signed-off-by: John Johansen <john.johansen@canonical.com>
Instead of specifying the font type and size, which will not work for
all display configuration, use the the default BOLD font that tkinter
supplies.
Signed-off-by: John Johansen <john.johansen@canonical.com>
Following the Security Technical Implementation Guide, it is better to
set the permissions to 0000 for the shadow file.
However, since PAM version 1.6.0, after this change [0], unix-chkpwd
will unconditionnaly read the shadow file. And with the previous
restriction, the binary has an access denied to the shadow which
blocks user authentications. Moreover the PAM changes is needed to fix
the CVE-2024-10041.
Giving the read caability to the unix-chkpwd profile allows it to
function properly. See bug report [1].
[0] - https://github.com/linux-pam/linux-pam/pull/686
[1] - https://bugzilla.suse.com/show_bug.cgi?id=1241678
Signed-off-by: vlefebvre <valentin.lefebvre@suse.com>
Allow gs to run from confined environment by explicitly allowing access
to /usr/bin/gs.
Signed-off-by: Maxime Bélair <maxime.belair@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1684
Approved-by: Ryan Lee <rlee287@yahoo.com>
Merged-by: Maxime Bélair <maxime.belair@canonical.com>
Creates an AA profile for ProFTPD. The profile has been tested on Oracular with version `1.3.8.b+dfsg-2ubuntu1`, using the source integration/unit tests and via FTP commands. As an FTP package any directory can be used for manipulating files. I've included read/write permissions to several usual locations located at the end of the profile. However these are too loose, any suggestions for how they could be tightened is much appreciated. Thanks!
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1524
Approved-by: Maxime Bélair <maxime.belair@canonical.com>
Merged-by: Maxime Bélair <maxime.belair@canonical.com>
Initial profile for review + extra descriptions to summarize why each rule / chunk is there.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1486
Approved-by: John Johansen <john@jjmx.net>
Merged-by: Maxime Bélair <maxime.belair@canonical.com>
The current Transmission related profiles are set to complain mode. I've tested on Oracular `transmission-daemon` and `transmission` with the profile enforced with no denials have occurred. This MR removes the complain flag on these profiles.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1534
Approved-by: John Johansen <john@jjmx.net>
Merged-by: Maxime Bélair <maxime.belair@canonical.com>
For now, also use a complain mode flag like with Xorg. However, it may be
possible for complain mode to be dropped from both in the future,
tightening confinement (especially since Xorg.wrap is setuid). A
complain-mode profile can still be useful for Xorg.wrap by giving it a
separate label.
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1665
Approved-by: Maxime Bélair <maxime.belair@canonical.com>
Merged-by: Ryan Lee <rlee287@yahoo.com>
It doesn't seem to need a lot of rules, and I've tried running upstream test suite with this profile and it passed.
Signed-off-by: Allen Huang <allen.huang@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1660
Approved-by: Maxime Bélair <maxime.belair@canonical.com>
Merged-by: Maxime Bélair <maxime.belair@canonical.com>
For now, also use a complain mode flag like with Xorg. However, it may be
possible for complain mode to be dropped from both in the future,
tightening confinement (especially since Xorg.wrap is setuid). A
complain-mode profile can still be useful for Xorg.wrap by giving it a
separate label.
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
Add AA profile for ghostscript. This profile has been tested on the latest plucky gs version 10.05.0dfsg1-0ubuntu1 while the latest upstream version is 10.05.0. This profile limits file access (read and write) to specific file extensions, printer devices in /dev and directories in /tmp.
The profile has been tested against the regression test suite we use in Ubuntu and manually. Testing against devices has been performed in a limited fashion as I only have access to one usb printer.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1590
Approved-by: Ryan Lee <rlee287@yahoo.com>
Merged-by: Maxime Bélair <maxime.belair@canonical.com>
Add AA profile for `nslookup`. This profile has been tested on the latest plucky `nslookup` version `9.20.4-3ubuntu1` (ultimately part of `dnsutils`). Functionality has been exercised as much as possible, including basic record lookups, querying specific DNS servers, performing reverse DNS lookups, querying a CNAME, querying an MX record, querying a txt record, querying a DNSSEC-related record, performing IPv4 & IPv6 lookups, and overriding to use a custom resolver. These tests were performed through command parsing and the interactive terminal mode. AFAIK, upstream does not have a test suite available for `nslookup`
Signed-off-by: john-breton <john.breton@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1619
Approved-by: Ryan Lee <rlee287@yahoo.com>
Approved-by: Maxime Bélair <maxime.belair@canonical.com>
Merged-by: Maxime Bélair <maxime.belair@canonical.com>
- Tested with different flags manually
- apparmor.d also have a profile for `hostname` which includes `<abstractions/consoles>` but was not needed while testing for plucky
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1650
Approved-by: Maxime Bélair <maxime.belair@canonical.com>
Approved-by: Ryan Lee <rlee287@yahoo.com>
Merged-by: Maxime Bélair <maxime.belair@canonical.com>
Add AA profile for /usr/bin/locale. This profile has been tested on the latest plucky version of locale (Ubuntu GLIBC 2.41-6-ubuntu1). This profile prevents write access to any file, limits read access to all files necessary for locale to work and limits execution of any other file other than the compressors (gzip/bzip2), which are also limited by a specific subprofile..
The profile has been tested manually.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1646
Approved-by: Ryan Lee <rlee287@yahoo.com>
Merged-by: Maxime Bélair <maxime.belair@canonical.com>
See the comment for an explanation of why CAP_SYS_ADMIN was being checked and why it isn't actually necessary for setting ionice values for processes
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1683
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
Follow up to MR !1637
`make check-parser` in profiles now verifies that all profiles allow at
least a read access to their attachment path.
This is done with test_profile.py, more robust and therefore replacing
test_profile.sh.
Additionally, fix the permission of 3 profiles, that were not detected by
!1637 due to a bug in a regex
Signed-off-by: Maxime Bélair <maxime.belair@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1657
Approved-by: Christian Boltz <apparmor@cboltz.de>
Merged-by: John Johansen <john@jjmx.net>
`make check-parser` in profiles now verifies that all profiles allow at
least a read access to their attachment path.
Signed-off-by: Maxime Bélair <maxime.belair@canonical.com>
test_profile.sh contained some bash-specific code and a bug in a regex
that failed to flag some profiles where read access to their attachment
path was not allowed.
Replace it with a Python script, more robust and maintenable.
Signed-off-by: Maxime Bélair <maxime.belair@canonical.com>
Have the parser extract the attachment path from the profile declaration
and make it available as a local 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
```
While not recommended for rules directly in a profile the above
the undeclared variable error can be avoided in in abstractions
by wrapping the variable in a conditional.
```
if defined @{attach_path} {
@{attach_path r,
}
```
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/-/me\
rge_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 series may cause breakage if policy declares either
@{attach_path} or @{exec_path} by shadowing those previously declared
variables in the profile block. The previously declared variable
is available in the attachment specification so uses like the
apparmor.d project won't break as it with transfer its variable
value to the attachment which will the transfer that value into
the automatic local var.
Signed-off-by: John Johansen <john.johansen@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1643
Approved-by: Maxime Bélair <maxime.belair@canonical.com>
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
See the comment for an explanation of why CAP_SYS_ADMIN was being checked and why it isn't actually necessary for setting ionice values for processes
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
Due to how labeling is implemented, during the creation it is not yet
defined, so we need to grant create permissions without attaching the
label yet. Also, adjust tests to pass when label support is
implemented in the kernel.
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1623
Approved-by: Maxime Bélair <maxime.belair@canonical.com>
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
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>
This patch updates the set of profiles updated by MR:1637, this is split
off from the rest of the profile updates because that set is explicity
recently set apart.
Signed-off-by: John Johansen <john.johansen@canonical.com>
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>
The spread pipeline was failing due to missing tests
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1682
Approved-by: Maxime Bélair <maxime.belair@canonical.com>
Approved-by: Georgia Garcia <georgia.garcia@canonical.com>
Merged-by: Georgia Garcia <georgia.garcia@canonical.com>
Due to how the debug information shows up when something fails in
spread the information is hard to figure out.
See this example when the allow_all test was missing
https://gitlab.com/apparmor/apparmor/-/jobs/9958642493
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
fuse_overlayfs requires noatime, but we should also allow more flags than
just that to preempt future breakage from flags not included in the rules.
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1673
Approved-by: Maxime Bélair <maxime.belair@canonical.com>
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
ipa_verify is a simple libcamera tool that does not use the portion of
libcamera that creates user namespaces. This simple profile should be
enough to replace the previous unconfined profile.
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1624
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
This includes testing for options in (list) by itself, along with a rudimentary test for the combination of options=(list) and options in (list).
In particular, the test for the combination confirms that the `apparmor.d` man page was wrong about what happens when these options are combined.
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1672
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
Specifying norelatime should set the corresponding MS_RELATIME flag clear
bit. Instead, it ORed in MS_NORELATIME, which expands to 0. Properly set
the clear bit by using MS_RELATIME.
Fixes: c9e31b7f "Add mount rules"
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1679
Approved-by: Georgia Garcia <georgia.garcia@canonical.com>
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
In particular, the dbus rules were completely rebuilt based on reading through wpa_supplicant's dbus source code.
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1630
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
... and drop rules that are part of abstractions/gtk
Note that abstractions/gtk contains more than the rules dropped here,
which means it effectively extends the permissions granted by
abstractions/gnome.
Idea by darix.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1678
Approved-by: Ryan Lee <rlee287@yahoo.com>
Merged-by: John Johansen <john@jjmx.net>
reported by darix
The initial radv_builtin_shaders rule was added in 4.1, therefore I propose this patch for at least 4.1 and master.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1677
Approved-by: Ryan Lee <rlee287@yahoo.com>
Merged-by: John Johansen <john@jjmx.net>
Reported by darix, seen with comm="sshd-session"
I propose this for master and 4.x (optionally also 3.x even if it's less likely that systems using these branches already use lastlog2)
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1676
Approved-by: Ryan Lee <rlee287@yahoo.com>
Merged-by: John Johansen <john@jjmx.net>
