This ideally is a temporary fix because we do not want to allow all users
of curl to be able to access the snapd socket. However, this will work for
now until we can mediate the accesses better.
Fixes: LP: #2120669
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
This MR contains fixes and improvements for --local profiles in aa-notify
- aa-notify: Make --local commandline option override use_local_profiles
- utils: Move get_local_include to ProfileStorage
- utils: Add tests for get_local_include
- aa-notify gui: Fix undefined variable when ttkthemes is not installed
Signed-off-by: Maxime Bélair <maxime.belair@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1770
Approved-by: Maxime Bélair <maxime.belair@canonical.com>
Merged-by: Maxime Bélair <maxime.belair@canonical.com>
The current profile is for linking against libnuma. This
update adds the rules needed to get system information
when actually using libnuma functionality.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1768
Approved-by: Georgia Garcia <georgia.garcia@canonical.com>
Approved-by: Christian Boltz <apparmor@cboltz.de>
Merged-by: Christian Boltz <apparmor@cboltz.de>
Fixes#449
Tkinter (used by aa-notify) needs the $XAUTHORITY envvar to start but on
some systems (e.g. OpenSuse), sudo clears it. This change add a
--xauthority command-line option to set it explicitly, so aa-notify works
under sudo.
Signed-off-by: Maxime Bélair <maxime.belair@canonical.com>
Closes#449
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1771
Approved-by: Christian Boltz <apparmor@cboltz.de>
Merged-by: Christian Boltz <apparmor@cboltz.de>
Fixes#449
Tkinter (used by aa-notify) needs the $XAUTHORITY envvar to start but on
some systems (e.g. OpenSuse), sudo clears it. This change add a
--xauthority command-line option to set it explicitly, so aa-notify works
under sudo.
Signed-off-by: Maxime Bélair <maxime.belair@canonical.com>
If both the --local commandline option and use_local_profiles
configuration are specified, the commandline now takes precedence.
Signed-off-by: Maxime Bélair <maxime.belair@canonical.com>
The current profile is for linking against libnuma. This
update adds the rules needed to get system information
when actually using libnuma functionality.
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Allow writing to local profiles
This notably allows aa-notify to write to local profiles instead of the main profile with the new `--local` option. This keeps the base profile clean, avoiding breakages when the system updates profiles.
Signed-off-by: Maxime Bélair <maxime.belair@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1764
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
aa-notify configuration now supports use_local_profiles, and this option
is documented in the manual.
Signed-off-by: Maxime Bélair <maxime.belair@canonical.com>
The new option --local allows user to write new rules to local profiles
instead of system profiles, enabling cleaner profile deployment.
This option support the values (yes, no and auto)
Signed-off-by: Maxime Bélair <maxime.belair@canonical.com>
This patch allows writing write in include files and save them to disk.
This is particularly helpful for local includes (generally used in
profiles through `include if exists <local/foo>`), and keeps the base
profile clean, avoiding breakages when the system updates profiles.
Signed-off-by: Maxime Bélair <maxime.belair@canonical.com>
For every item in "cases", a new state is created, but if the creation
of one of them fails, the rest of the items in that list would not be
deleted and would leak. Fix it by continuing to iterate over the items
in the list and delete them, and then re-throw the exception.
$ /usr/bin/valgrind --leak-check=full --error-exitcode=151 ../apparmor_parser -Q -I simple_tests/ -M ./features_files/features.all simple_tests/xtrans/x-conflict.sd
==564911== 208 (48 direct, 160 indirect) bytes in 1 blocks are definitely lost in loss record 15 of 19
==564911== at 0x4846FA3: operator new(unsigned long) (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==564911== by 0x179E74: CharNode::follow(Cases&) (expr-tree.h:447)
==564911== by 0x189F8B: DFA::update_state_transitions(optflags const&, State*) (hfa.cc:376)
==564911== by 0x18A25B: DFA::process_work_queue(char const*, optflags const&) (hfa.cc:442)
==564911== by 0x18CB65: DFA::DFA(Node*, optflags const&, bool) (hfa.cc:486)
==564911== by 0x178263: aare_rules::create_chfa(int*, std::vector<aa_perms, std::allocator<aa_perms> >&, optflags const&, bool, bool) (aare_rules.cc:258)
==564911== by 0x178A4F: aare_rules::create_dfablob(unsigned long*, int*, std::vector<aa_perms, std::allocator<aa_perms> >&, optflags const&, bool, bool) (aare_rules.cc:359)
==564911== by 0x14E4E1: process_profile_regex(Profile*) (parser_regex.c:791)
==564911== by 0x154CDF: process_profile_rules(Profile*) (parser_policy.c:194)
==564911== by 0x154E0F: post_process_profile(Profile*, int) (parser_policy.c:240)
==564911== by 0x154F7A: post_process_policy_list (parser_policy.c:257)
==564911== by 0x154F7A: post_process_policy(int) (parser_policy.c:267)
==564911== by 0x141B17: process_profile(int, aa_kernel_interface*, char const*, aa_policy_cache*) (parser_main.c:1227)
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/534
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
When the "conflicting x modifiers" exception was thrown, the DFA
object creation would fail, therefore the destructor would not be
called and the states previously allocated would leak.
Unfortunately there's no way to call the destructor if the object was
not created, so I moved the contents of the destructor into a cleanup
helper function to be called in both instances.
$ /usr/bin/valgrind --leak-check=full --error-exitcode=151 ../apparmor_parser -Q -I simple_tests/ -M ./features_files/features.all simple_tests/xtrans/x-conflict.sd
==564911== 592 (112 direct, 480 indirect) bytes in 1 blocks are definitely lost in loss record 16 of 19
==564911== at 0x4846FA3: operator new(unsigned long) (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==564911== by 0x189C9A: DFA::add_new_state(optflags const&, std::set<ImportantNode*, std::less<ImportantNode*>, std::allocator<ImportantNode*> >*, std::set<ImportantNode*, std::less<ImportantNode*>, std::allocator<ImportantNode*> >*, State*) (hfa.cc:337)
==564911== by 0x18CB22: add_new_state (hfa.cc:357)
==564911== by 0x18CB22: DFA::DFA(Node*, optflags const&, bool) (hfa.cc:473)
==564911== by 0x178263: aare_rules::create_chfa(int*, std::vector<aa_perms, std::allocator<aa_perms> >&, optflags const&, bool, bool) (aare_rules.cc:258)
==564911== by 0x178A4F: aare_rules::create_dfablob(unsigned long*, int*, std::vector<aa_perms, std::allocator<aa_perms> >&, optflags const&, bool, bool) (aare_rules.cc:359)
==564911== by 0x14E4E1: process_profile_regex(Profile*) (parser_regex.c:791)
==564911== by 0x154CDF: process_profile_rules(Profile*) (parser_policy.c:194)
==564911== by 0x154E0F: post_process_profile(Profile*, int) (parser_policy.c:240)
==564911== by 0x154F7A: post_process_policy_list (parser_policy.c:257)
==564911== by 0x154F7A: post_process_policy(int) (parser_policy.c:267)
==564911== by 0x141B17: process_profile(int, aa_kernel_interface*, char const*, aa_policy_cache*) (parser_main.c:1227)
==564911== by 0x135421: main (parser_main.c:1771)
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/534
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
Valgrind showed that the disconnected paths variables were leaking
during the merge. That happened because flagvals did not implement a
destructor freeing the variables, so they leaked. flagvals cannot
implement a destructor, because that would make it a non-trivial union
member and parser_yacc.y would not compile. This patch implements a
"clear" function that is supposed to act as the destructor.
$ /usr/bin/valgrind --leak-check=full --error-exitcode=151 ../apparmor_parser -Q -I simple_tests/ -M ./features_files/features.all flags_ok_disconnected_ipc15.sd
...
==3708747== 5 bytes in 1 blocks are definitely lost in loss record 1 of 11
==3708747== at 0x4846828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==3708747== by 0x492E35E: strdup (strdup.c:42)
==3708747== by 0x14C74E: set_disconnected_path (profile.h:188)
==3708747== by 0x14C74E: flagvals::init(char const*) (profile.h:223)
==3708747== by 0x14859B: yyparse() (parser_yacc.y:592)
==3708747== by 0x141A99: process_profile(int, aa_kernel_interface*, char const*, aa_policy_cache*) (parser_main.c:1187)
==3708747== by 0x135421: main (parser_main.c:1771)
...
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
GDM 49~beta implements a userdb VarLink service for managing the unix users
running the greeter shell, as well as the gnome-initial-setup users.
```
gdm-launch-environment][1892]: Gdm: GdmSessionWorker: determining if authenticated user (password required:0) is authorized to session
unix_chkpwd[1897]: could not obtain user info (gdm-greeter)
kernel: audit: type=1400 audit(1754399331.488:211): apparmor="DENIED" operation="connect" class="file" profile="unix-chkpwd" name="/run/systemd/userdb/org.gnome.DisplayManager" pid=1897 comm="unix_chkpwd" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
gdm-launch-environment][1892]: Gdm: GdmSessionWorker: user is not authorized to log in: Authentication failure
```
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1761
Approved-by: Ryan Lee <rlee287@yahoo.com>
Merged-by: John Johansen <john@jjmx.net>
GDM 49~beta implements a userdb VarLink service for managing the unix users
running the greeter shell, as well as the gnome-initial-setup users.
gdm-launch-environment][1892]: Gdm: GdmSessionWorker: determining if authenticated user (password required:0) is authorized to session
unix_chkpwd[1897]: could not obtain user info (gdm-greeter)
kernel: audit: type=1400 audit(1754399331.488:211): apparmor="DENIED" operation="connect" class="file" profile="unix-chkpwd" name="/run/systemd/userdb/org.gnome.DisplayManager" pid=1897 comm="unix_chkpwd" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
gdm-launch-environment][1892]: Gdm: GdmSessionWorker: user is not authorized to log in: Authentication failure
LP: #2119541
perms = 0, therefore perms & something is always false.
Fixes: coverity#320937 and coverity#320937
Also remove nop code from mnt_rule::post_parse_profile(Profile &prof) as discussed in this MR.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1759
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
When the variable was being expanded, it needed to be reevaluated to
check if there was still unresolved variables. That allowed for a
weird bug to happen: If the string contained a variable preceded by @,
like in "user@@{uid}" and the variable was resolved to a case where {
is used, like in @{uid}={[0-9],[1-9][0-9]}, then on the second pass,
the parser would try to resolve the following variable
@{[0-9],[1-9][0-9]}, which is incorrect behavior. Fix it by not
including part of the string that was already resolved on the
subsequent passes.
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1756
Approved-by: Steve Beattie <steve+gitlab@nxnw.org>
Merged-by: Steve Beattie <steve+gitlab@nxnw.org>
When the variable was being expanded, it needed to be reevaluated to
check if there was still unresolved variables. That allowed for a
weird bug to happen: If the string contained a variable preceded by @,
like in "user@@{uid}" and the variable was resolved to a case where {
is used, like in @{uid}={[0-9],[1-9][0-9]}, then on the second pass,
the parser would try to resolve the following variable
@{[0-9],[1-9][0-9]}, which is incorrect behavior. Fix it by not
including part of the string that was already resolved on the
subsequent passes.
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
The xtable on perms32 capable systems is being padded to the size of
the accept state tables. This was a hack to get around issue in a buggy
perms32 v1. We do not support any system using perms 32 v1 so we can
drop the hack.
Similarly since we don't support perms32v1 we don't support prompt
compat dev or perms32v1, so drop them as well
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1750
Approved-by: Ryan Lee <rlee287@yahoo.com>
Merged-by: John Johansen <john@jjmx.net>
Their is no reason for the parse to stitch 2 dfas together this way.
In the future there will be better ways to do this using unconpressed
dfas.
Dropping this also allows for some simplification, in other parts of
the code.
Drop the dead/unused code
Signed-off-by: John Johansen <john.johansen@canonical.com>
prompt_compat_permsv1 and prompt_compat_dev were used to support
prompt during early dev. We do not support any kernel using these
so drop them.
This also allows us to drop the propogation of prompt as a parameter
through several functions.
Signed-off-by: John Johansen <john.johansen@canonical.com>
The xtable on perms32 capable systems is being padded to the size of
the accept state tables. This was a hack to get around issue in a buggy
perms32 v1. We do not support any system using perms 32 v1 so we can
drop the hack.
Signed-off-by: John Johansen <john.johansen@canonical.com>
Right now coverity is running in two steps, one to collect logs in
case of failures, and a different one to actually send the data to
coverity. The log collection step is failing because when collecting
data for python with the new version of coverity, build-log.txt is not
generated.
The whole way we build with coverity might need changing, but
currently this patch is removing the log collection so the pipeline
passes.
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1754
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
Right now coverity is running in two steps, one to collect logs in
case of failures, and a different one to actually send the data to
coverity. The log collection step is failing because when collecting
data for python with the new version of coverity, build-log.txt is not
generated.
The whole way we build with coverity might need changing, but
currently this patch is removing the log collection so the pipeline
passes.
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
