The problem description in the GitHub issue was:
The following is how i noticed. It gave me the following error when i tried to start my virtual system: The VirtualBox Linux kernel driver is either not loaded or not set up correctly. Please try setting it up again by executing
'/sbin/vboxconfig'
as root.
Which i did, however it didn't work due to some permission problems.
It failed and told me to use dmesg to find out why. When i used dmesg i saw what it did in the background.
I picked two messages out of many:
And the log messages:
audit: type=1400 audit(1651914430.711:1128): apparmor="DENIED" operation="open" profile="torbrowser_firefox"
name="/home/amnesia/.cache/thumbnails/large/3678dc849747c84908498dd948db8f71.png"
pid=10995 comm="pool-firefox"
requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
This message was generated by AppArmor blocking read access by a process 10995 named pool-firefox running as user ID 1000 to the local file manager's thumbnail image cache.
I don't see anything here indicating this message would be in any way connected to executing /sbin/vboxconfig as root. It's more likely that the user simply had a Firefox file dialog open (for whatever reason) and the dialog library was looking for image thumbnails, but because the library was executed as part of a web browser, the AppArmor rules of the privacy-focused distribution blocked the access (to prevent the possibility of exfiltration of local thumbnail cache via the browser).
Dropped outbound packet: IN= OUT=wlan0 SRC=i removed the adress DST=i removed the adress LEN=48 TC=0 HOPLIMIT=255 FLOWLBL=762031 PROTO=ICMPv6 TYPE=133 CODE=0 UID=0 GID=0
ICMPv6 type 133 is a Router Solicitation packet, i.e. this system is sending out a packet on wlan0, requesting the IPv6 router(s) on the WiFi network to announce themselves.
It is a part of the normal functionality of IPv6 auto-configuration, and UID=0 indicates the packet was generated by a root-level process. Normally such packets are sent out as multicasts to the link-local "all-routers" IPv6 multicast address, so if the DST= address was anything other than ff02::2, it would indicate abnormal use, possibly suggesting that the ICMPv6 messages may be being used as a covert data exfiltration channel.
But an attack of such complexity (that already requires privileged access to craft custom ICMPv6 messages) while not removing the iptables filter blocking and revealing it would be inconsistent, strongly suggesting that this may be a misinterpretation by the user.
I don't see any evidence of a causal connection between the original action, the first log message and/or this second one.
This looks more like a common logical fallacy: "Since event Y followed event X, event Y must have been caused by event X." ("post hoc ergo propter hoc")
In this case, the user simply assumes that the log messages are resulting exclusively from them running the /sbin/vboxconfig command, when in actuality there are many other processes happening on the system at the same time, and dmesg reports on all of them.
