@arraybolt3 does browser choice ship any separate apparmor that are not already included with kicksecure? Might be a good idea to look at and readjust, or add any that aren’t shipped for these browsers in browser choice. I noticed sum things when looking at AA rules, but I’ll post them elsewhere.
For a very technical answer that’s what you asked for but not what you wanted to ask for, no. browser-choice is already included with Kicksecure, so any AppArmor profiles it ships now or in the future are included with Kicksecure. 
For an answer closer to what you wanted but probably still not quite there, also no. browser-choice itself includes zero AppArmor profiles (as you can verify by visiting GitHub - Kicksecure/browser-choice: Browser choice for Kicksecure - lets the user pick the default browser at first run · GitHub and searching for “apparmor” in the “Go to file” box). No part of browser-choice itself needs confined by AppArmor, so there is no need for additional profiles.
I think what you meant to ask is, does browser-choice provide AppArmor profiles that confine individual web browsers beyond the level of confinement they would have by default? To answer that, no, browser-choice doesn’t ship any configuration, AppArmor profiles or otherwise, that alter the behavior of a browser. It is only an installer, and will very likely remain that way by design. Developing special configuration for a web browser is essentially in-house browser development, which we explicitly avoid:
(We do a little bit of pre-configuration for Tor Browser, but that’s an exception to the rule since Tor Browser is essential to Whonix, and we need special configuration for Tor Browser for it to work with Whonix.)
2 Likes
Brave does not ship a apparmor profile by default.
One does ship one via apparmor.d brave profile and might I say it looks pretty locked down while not being too restrictive.
Had to put my readers on cuz I almost read that it granted access to calling abstractions/bus/ like network-manager-observe. Which means it could possibly call a interfaces HwAddress via D-Bus but it looks like it doesn’t have D-Bus access to NetworkManager 
example dbus call with device 2 which is my eth0 in my case
dbus-send --system --print-reply \
--dest=org.freedesktop.NetworkManager \
/org/freedesktop/NetworkManager/Devices/2 \
org.freedesktop.DBus.Properties.Get \
string:org.freedesktop.NetworkManager.Device \
string:HwAddress
my output
method return time=1789741162.642122 sender=:1.99 -> destination=:1.390 serial=084 reply_serial=2
variant string "E8:6C:DA:2C:BD:9F"
Note that apparmor.d is not a Kicksecure project, that’s a fork of it we have for some development investigation. It doesn’t ship as part of Kicksecure yet, although it could at some (undefined but likely distant) point in the future.
Be aware that AppArmor in Debian Trixie does not have working UNIX socket or D-Bus mediation, therefore any process that has any access to UNIX sockets has full access to D-Bus. This will hopefully be fixed in Debian Forky with AppArmor 5.
1 Like
Ohh ok thanks I was under the impression it was bundled in but thanks for clarifying that up.
I’ll have to try to track that progress on Forky and mailing lists. Thanks for the heads up on that.