Full System AppArmor Policy - Testers Wanted!

News
64

Unless you’re a developer and can send pull requests to fix these issues or specifically instructed to temporarily use the developers repository (I don’t think we ever did that yet), please do not use that repository.

I am aware of these issues. These changes aren’t ready yet for testers (the testers repository).
After these changes are ready however these might not immediately compatible with apparmor-profile-everything.

Not too bad but weird. Shouldn’t be done that way. Also since Tor as part of Tor Browser does not run inside Whonix-Workstation that will do effectivly nothing.

65

Again, sdwdate is not meant to be run from the command line.

Please don’t deviate from the standard configuration. It will just cause confusion.

1 Like
66

Hello! Decided to try this out on the latest testing version and after installing that and restarting Whonix, I get this error message when trying to update. Any ideas are welcome. Total noobie when it comes to finding logs and stuff, but I’ll dig in for it in an hour or so.

Edit: It also seems to have broken guest additions for me.

user@host:~$ upgrade-nonroot
Reading package lists…
W: chown to _apt:root of directory /var/lib/apt/lists/partial failed - SetupAPTPartialDirectory (13: Permission denied)
W: chmod 0700 of directory /var/lib/apt/lists/partial failed - SetupAPTPartialDirectory (13: Permission denied)
W: chown to _apt:root of directory /var/lib/apt/lists/auxfiles failed - SetupAPTPartialDirectory (13: Permission denied)
W: chmod 0700 of directory /var/lib/apt/lists/auxfiles failed - SetupAPTPartialDirectory (13: Permission denied)
E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied)
E: Unable to lock directory /var/lib/apt/lists/
W: Problem unlinking the file /var/cache/apt/pkgcache.bin - RemoveCaches (13: Permission denied)
W: Problem unlinking the file /var/cache/apt/srcpkgcache.bin - RemoveCaches (13: Permission denied)

Link to a systemd log:
https://p.teknik.io/SvSa8

67

Coming back to apparmor-profile-everything today from my post in Jan, sdwdate is still broken and xorg has a new DENIED that disables me from entering the OS:

AVC apparmor=“DENIED” operation=“open” profile=“Xorg” name=“/sys/devices/pci0000:00/0000:00:02.0/0000:03:00.0/vendor” comm=“Xorg” requested_mask=“r” denied_mask=“r”
AVC apparmor=“DENIED” operation=“open” profile=“Xorg” name=“/sys/devices/pci0000:00/0000:00:02.0/0000:03:00.0/config” comm=“Xorg” requested_mask=“r” denied_mask=“r”
AVC apparmor=“DENIED” operation=“open” profile=“init-systemd” name=“/sys/power/state” comm=“systemd-logind” requested_mask=“r” denied_mask=“r”

I have this added within my Xorg profile:

/sys/devices/pci[0-9]/{,drm/} r,
/sys/devices/pci[0-9]/sound/card[0-9]*/id r,

What needs to be added and has the sdwdate issue been solved, does sdwdate work with the stable version of apparmor-profile-everything? I donated about 2000 in bitcoin to your project around Jan when I was trying to get this to work and it seems like this particular project is dead?

1 Like
68

If you like to donate for a specific feature… If can proof the donation [1], I can forward it to @madaidan.

[1] By signing a message from the sending BTC address. (To save you some effort, this can wait until/if @madaidan gets back and agrees, thinks that is welcome/would be helpful or …)

69

I don’t have the donation signature as I wish to remain anon.

This is my dmesg output:

[ 28.083777] audit: type=1400 audit(1621973175.441:84): apparmor=“DENIED” operation=“open” profile=“Xorg” name=“/sys/devices/pci0000:00/0000:00:02.0/0000:03:00.0/vendor” pid=972 comm=“Xorg” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0
[ 28.084029] audit: type=1400 audit(1621973175.441:85): apparmor=“DENIED” operation=“open” profile=“Xorg” name=“/sys/devices/pci0000:00/0000:00:02.0/0000:03:00.0/config” pid=972 comm=“Xorg” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0
[ 28.088635] audit: type=1400 audit(1621973175.445:86): apparmor=“DENIED” operation=“open” profile=“Xorg” name=“/sys/devices/pci0000:00/0000:00:02.0/0000:03:00.0/vendor” pid=972 comm=“Xorg” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0
[ 28.089072] audit: type=1400 audit(1621973175.445:87): apparmor=“DENIED” operation=“open” profile=“Xorg” name=“/sys/devices/pci0000:00/0000:00:02.0/0000:03:00.0/config” pid=972 comm=“Xorg” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0
[ 28.539758] audit: type=1400 audit(1621973175.897:88): apparmor=“DENIED” operation=“open” profile=“Xorg” name=“/sys/devices/pci0000:00/0000:00:02.0/0000:03:00.0/vendor” pid=995 comm=“Xorg” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0
[ 28.539767] audit: type=1400 audit(1621973175.897:89): apparmor=“DENIED” operation=“open” profile=“Xorg” name=“/sys/devices/pci0000:00/0000:00:02.0/0000:03:00.0/config” pid=995 comm=“Xorg” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0
[ 28.544571] audit: type=1400 audit(1621973175.901:90): apparmor=“DENIED” operation=“open” profile=“Xorg” name=“/sys/devices/pci0000:00/0000:00:02.0/0000:03:00.0/vendor” pid=995 comm=“Xorg” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0
[ 28.544580] audit: type=1400 audit(1621973175.901:91): apparmor=“DENIED” operation=“open” profile=“Xorg” name=“/sys/devices/pci0000:00/0000:00:02.0/0000:03:00.0/config” pid=995 comm=“Xorg” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0
[ 28.758401] audit: type=1400 audit(1621973176.113:92): apparmor=“DENIED” operation=“open” profile=“init-systemd” name=“/sys/power/state” pid=766 comm=“systemd-logind” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0
[ 28.761266] audit: type=1400 audit(1621973176.117:93): apparmor=“DENIED” operation=“open” profile=“init-systemd” name=“/sys/power/state” pid=766 comm=“systemd-logind” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0

I noticed in the stable release of apparmor-profile-everything that you have this in Xorg profile:

@{sys}/devices/**/{uevent,name} r,
@{sys_pci}/{device,revision,subsystem_device,subsystem_vendor,class,vendor,boot_vga,config,resource,drm/,sound/card[0-9]*/id} r,

I’m thinking a term has not been added to cater to this denied. This is from a new Kicksecure installation that I just performed and installed apparmor-profile-everything today.

The video card in question is an AMD card.

70

rapt must be used.

71

With the information on the donation already posted [1] it might be possible to figure out which transaction was yours anyhow. Seems quite doable to me. Assuming that, signing a message from that BTC address wouldn’t leak any additional information.

[1] You might want do delete that if you don’t want that public correlated to this account.

72

Since development stalled… Getting too time consuming, complex, daunting? I got an idea to simplify things.

The Whonix firewall AppArmor profile still unfixed. Do we really need a “real” AppArmor profile for Whonix firewall? That script is trusted anyhow.

(Trusted because required. Not because wanted.)

It doesn’t have any relevant attack surface. It’s in a location that should be coneptually only writeable by superadmin.

Going a step back… Due to AAE, now most/all binaries need an AppArmor profile. Otherwise they inherit the default / “everyone’s” AppArmor profile. That is insufficient for Whonix firewall.

To simplify this case and perhaps other related cases, couldn’t we instead just have a passthrough AppArmor profile that permits everything?

And also timesanitycheck. Did we really need an AppArmor profile for timesanitycheck which conceptually has no attack surface? It’s in locations which conceptually should only be wirteable by superadmin. Therefore it could either have a passthorugh AppArmor profile or even be allowed to be run unconfined? That seems a lot simpler than inventing tailored AppArmor profiles for things which conceptually have no attack surface. Otherwise is it still realistic that this will ever reach production level quality?

73

This should be allowed: https://github.com/Whonix/apparmor-profile-everything/blob/master/etc/apparmor.d/usr.lib.xorg.Xorg#L57

Does the policy on your system have this line?

Those wouldn’t solve the denial errors you posted above.

It should work, provided one is using it in the expected configuration and not running it from the command line.

It’s not dead; I’ve just been busy with other stuff recently and haven’t had much time to focus on Whonix.

It would certainly be helpful. I don’t have a crypto wallet currently, but I’ve been meaning to set one up.

The purpose of the whonix-firewall, timesanitycheck and similar profiles are not really to confine those services, but so we can remove certain capabilities from the overall profile. For example, whonix-firewall is the only thing that needs the CAP_NET_ADMIN capability (for setting firewall rules) so if we run it in its own profile, we can exclude that from the init-systemd profile and only grant it in the whonix-firewall profile, thereby preventing even a privileged attacker on the gateway from bypassing the Tor enforcement. Likewise, only a few services need CAP_SYS_TIME (sdwdate and timesanitycheck) so by giving those their own profiles, we can exclude that from the main profile also.

That would add significant attack surface.

1 Like
74

I don’t really see any attack surface / threat model for timesanitycheck. Please explain.

75

The attack surface is not in timesanitycheck but rather in just having an unconfined profile on the system at all. It would be the weakest link in the policy. If an attacker gets access to that for any reason, it’s game over. Even if we can’t figure out a way on how to get access to it right now, an attacker will.

1 Like
76

Alright. Make sense. Just don’t let the perfect (and too hard to create / maintain) be the enemy of the good. :slight_smile:

PM’d on telegram.

1 Like
77

I’ll start fresh with a new Kicksecure install with Whonix VMs and will report back soon.

My setup is Kicksecure with lkrg and hardened kernel along with Whonix VMs in KVM also using hardened kernel with lkrg.

The goal is to use Kicksecure as host with Whonix for work.

1 Like
78

I was able to do a fresh install of Kicksecure with hardened-kernel and LKRG installed. I installed apparmor-profile-everything and I receive a blinking underscore screen. This usually is something to do with lightdm or xorg. I then F12 and login via the terminal, and enter dmesg:

27.167825] audit: type=1400 audit(1622638817.178:58): apparmor=“DENIED” operation=“open” profile=“Xorg” name=“/sys/devices/pci0000:00/0000:00:03.0/0000:04:00.0/vendor” pid=952 comm=“Xorg” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0

[ 27.167835] audit: type=1400 audit(1622638817.178:59): apparmor=“DENIED” operation=“open” profile=“Xorg” name=“/sys/devices/pci0000:00/0000:00:03.0/0000:04:00.0/config” pid=952 comm=“Xorg” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0
[ 27.174747] audit: type=1400 audit(1622638817.186:60): apparmor=“DENIED” operation=“open” profile=“Xorg” name=“/sys/devices/pci0000:00/0000:00:03.0/0000:04:00.0/vendor” pid=952 comm=“Xorg” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0
[ 27.174757] audit: type=1400 audit(1622638817.186:61): apparmor=“DENIED” operation=“open” profile=“Xorg” name=“/sys/devices/pci0000:00/0000:00:03.0/0000:04:00.0/config” pid=952 comm=“Xorg” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0
[ 27.548757] audit: type=1400 audit(1622638817.558:62): apparmor=“DENIED” operation=“open” profile=“Xorg” name=“/sys/devices/pci0000:00/0000:00:03.0/0000:04:00.0/vendor” pid=987 comm=“Xorg” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0
[ 27.548793] audit: type=1400 audit(1622638817.558:63): apparmor=“DENIED” operation=“open” profile=“Xorg” name=“/sys/devices/pci0000:00/0000:00:03.0/0000:04:00.0/config” pid=987 comm=“Xorg” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0
[ 27.556309] audit: type=1400 audit(1622638817.566:64): apparmor=“DENIED” operation=“open” profile=“Xorg” name=“/sys/devices/pci0000:00/0000:00:03.0/0000:04:00.0/vendor” pid=987 comm=“Xorg” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0
[ 27.556325] audit: type=1400 audit(1622638817.566:65): apparmor=“DENIED” operation=“open” profile=“Xorg” name=“/sys/devices/pci0000:00/0000:00:03.0/0000:04:00.0/config” pid=987 comm=“Xorg” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0
[ 27.730511] audit: type=1400 audit(1622638817.742:66): apparmor=“DENIED” operation=“open” profile=“Xorg” name=“/sys/devices/pci0000:00/0000:00:03.0/0000:04:00.0/vendor” pid=1000 comm=“Xorg” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0
[ 27.730522] audit: type=1400 audit(1622638817.742:67): apparmor=“DENIED” operation=“open” profile=“Xorg” name=“/sys/devices/pci0000:00/0000:00:03.0/0000:04:00.0/config” pid=1000 comm=“Xorg” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0

This is a fresh install from the stable repo. I’m using an older AMD card for this PC to just serve 2D.

Also, same issue from a few months back with the sdwdate GUI app that doesn’t show the log nor does it update the status.

I believe that is the only 2 issues at this time as everything else seems to work.

Thanks,
sudobash

2 Likes
79

Ah, I can see the issue here. There’s a 3rd subdirectory not covered by the existing rules. Try editing /etc/apparmor.d/tunables/init-systemd and change the sys_pci tunable to the following:

@{sys_pci}=@{sys}/devices/pci@{sys_pci_numbers}/@{sys_pci_numbers}:*.*/{,@{sys_pci_numbers}:*.*/}

Does that fix it?

1 Like
80

I edited the file:

## Copyright (C) 2012 - 2021 ENCRYPTED SUPPORT LP <adrelanos@whonix.org>
## See the file COPYING for copying conditions.

@{sys_pci_numbers}=[0-9][0-9][0-9][0-9]:[0-9][0-9]
@{sys_pci}=@{sys}/devices/pci@{sys_pci_numbers}/@{sys_pci_numbers}:*.*/{,@{sys_pci_numbers}:*.*/}
@{dev_ttys}=/dev/tty{,S}[0-9]{,[0-9]}

Reboot and same issue where the terminal states lightdm cannot start. I F12 and run dmesg, at the bottom states:

[   40.091338] audit: type=1400 audit(1622782467.894:50): apparmor="DENIED" operation="open" profile="Xorg" name="/sys/devices/pci0000:00/0000:00:00.0/vendor" pid=1010 comm="Xorg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[   40.091350] audit: type=1400 audit(1622782467.894:51): apparmor="DENIED" operation="open" profile="Xorg" name="/sys/devices/pci0000:00/0000:00:00.0/config" pid=1010 comm="Xorg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[   40.091532] audit: type=1400 audit(1622782467.894:52): apparmor="DENIED" operation="open" profile="Xorg" name="/sys/devices/pci0000:00/0000:00:00.0/vendor" pid=1010 comm="Xorg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[   40.091544] audit: type=1400 audit(1622782467.894:53): apparmor="DENIED" operation="open" profile="Xorg" name="/sys/devices/pci0000:00/0000:00:00.0/config" pid=1010 comm="Xorg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[   40.780770] audit: type=1400 audit(1622782468.582:54): apparmor="DENIED" operation="open" profile="Xorg" name="/sys/devices/pci0000:00/0000:00:00.0/vendor" pid=1086 comm="Xorg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[   40.780785] audit: type=1400 audit(1622782468.582:55): apparmor="DENIED" operation="open" profile="Xorg" name="/sys/devices/pci0000:00/0000:00:00.0/config" pid=1086 comm="Xorg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[   40.780960] audit: type=1400 audit(1622782468.582:56): apparmor="DENIED" operation="open" profile="Xorg" name="/sys/devices/pci0000:00/0000:00:00.0/vendor" pid=1086 comm="Xorg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[   40.780973] audit: type=1400 audit(1622782468.582:57): apparmor="DENIED" operation="open" profile="Xorg" name="/sys/devices/pci0000:00/0000:00:00.0/config" pid=1086 comm="Xorg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[   41.025100] audit: type=1400 audit(1622782468.826:58): apparmor="DENIED" operation="open" profile="Xorg" name="/sys/devices/pci0000:00/0000:00:00.0/vendor" pid=1094 comm="Xorg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[   41.025113] audit: type=1400 audit(1622782468.826:59): apparmor="DENIED" operation="open" profile="Xorg" name="/sys/devices/pci0000:00/0000:00:00.0/config" pid=1094 comm="Xorg" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

I know this is a formatting issue but I’m not elite like you madaidan!

I noticed this:

profile=“Xorg” name=“/sys/devices/pci0000:00/0000:00:00.0/vendor” pid=1010 comm=“Xorg”

You’ll notice pci0000:00/0000:00:00.0 has a period followed by a zero.

The formating in your file is:

@{sys_pci_numbers}=[0-9][0-9][0-9][0-9]:[0-9][0-9]

How would we format pci0000:00/0000:00:00.0 in this regard?

Thanks,
sudobash

2 Likes
81

Perhaps it’s an issue with the @{sys} tunable since tunables/init-systemd does not include tunables/global (I had assumed it would be inherited from the actual profile, but maybe not?). Try editing /etc/apparmor.d/tunables/init-systemd and replace @{sys} with /sys or adding #include <tunables/global> to the top of the file. I.e.

@{sys_pci}=/sys/devices/...

or

## Copyright (C) 2012 - 2021 ENCRYPTED SUPPORT LP <adrelanos@whonix.org>
## See the file COPYING for copying conditions.

#include <tunables/global>

@{sys_pci_numbers}=[0-9][0-9][0-9][0-9]:[0-9][0-9]
@{sys_pci}=@{sys}/devices/...
...

That should already be covered by @{sys_pci_numbers}:*.* in @{sys_pci}.

2 Likes
82

I was only able to get past lightdm with this added to /etc/apparmor.d/tunables/:

## Copyright (C) 2012 - 2021 ENCRYPTED SUPPORT LP <adrelanos@whonix.org>
## See the file COPYING for copying conditions.

@{sys_pci_numbers}=[0-9,a-z][0-9,a-z][0-9,a-z][0-9,a-z]:[0-9,a-z][0-9,a-z]
@{sys_pci}=/sys/devices/***
@{dev_ttys}=/dev/tty{,S}[0-9]{,[0-9]}

I tried the 3 dots, no go, the asterisk seems to work which brought up other denieds so I added this to /etc/apparmor.d/local/usr.bin.dbus-daemon:

/run/systemd/sessions/*.ref w,
/run/systemd/inhibit/*.ref w,

I added these to /etc/apparmor.d/local/init-systemd for more denieds:

/sys/power/state r, 
/dev/tty1 rw,
/sys/class/ r,

I did a reboot and checked dmesg, new denieds came:

[   48.113020] audit: type=1400 audit(1623060317.967:50): apparmor="DENIED" operation="signal" profile="dbus-daemon" pid=1082 comm="systemd" requested_mask="receive" denied_mask="receive" signal=term peer="init-systemd"
[   48.113281] audit: type=1400 audit(1623060317.971:51): apparmor="DENIED" operation="signal" profile="dbus-daemon" pid=1082 comm="systemd" requested_mask="receive" denied_mask="receive" signal=kill peer="init-systemd"
[   48.113431] audit: type=1400 audit(1623060317.971:52): apparmor="DENIED" operation="signal" profile="dbus-daemon" pid=1082 comm="systemd" requested_mask="receive" denied_mask="receive" signal=term peer="init-systemd"
[   48.113623] audit: type=1400 audit(1623060317.971:53): apparmor="DENIED" operation="signal" profile="dbus-daemon" pid=1082 comm="systemd" requested_mask="receive" denied_mask="receive" signal=kill peer="init-systemd"
[   60.348617] audit: type=1400 audit(1623060330.203:54): apparmor="DENIED" operation="open" profile="/**/*-browser/Browser/firefox" name="/proc/1486/cgroup" pid=1486 comm="firefox.real" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000

I added this to /etc/apparmor.d/local/usr.bin.dbus-daemon for the new denieds:

signal receive set=term,
signal receive set=kill,

sdwdate does not work by running sdwdate in terminal:

2021-06-07 10:14:34 - sdwdate - INFO - sdwdate started. PID: 1896
Traceback (most recent call last):
  File "/usr/bin/sdwdate", line 10, in <module>
    sdwdate.main()
  File "/usr/lib/python3/dist-packages/sdwdate/sdwdate.py", line 1022, in main
    global_files()
  File "/usr/lib/python3/dist-packages/sdwdate/sdwdate.py", line 974, in global_files
    Path(sdwdate_status_files_folder).mkdir(parents=True, exist_ok=True)
  File "/usr/lib/python3.7/pathlib.py", line 1251, in mkdir
    self._accessor.mkdir(self, mode)
PermissionError: [Errno 13] Permission denied: '/home/user/sdwdate'

Also swdate-gui throws up an error, I realized sdwdate-gui isn’t in the sdwdate apparmor profile.

access control disabled, clients can connect from any host
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-sdwdate-gui'
tor_status_changed unexpected error: <class 'NameError'>

I do have a better understanding of apparmor now due to this thread so I appreciate everyone’s help on this forum especially madaidan!

On reboot, another denied:

[ 59.175475] audit: type=1400 audit(1623061641.571:50): apparmor=“DENIED” operation=“signal” profile=“dbus-daemon” pid=1068 comm=“systemd” requested_mask=“receive” denied_mask=“receive” signal=cont peer=“init-systemd”

So I added to /etc/apparmor.d/local/usr.bin.dbus-daemon:

signal receive set=cont,

Reboot and no denieds, just some unconfineds:

[ 26.120617] audit: type=1400 audit(1623062030.560:6): apparmor=“STATUS” operation=“profile_load” profile=“unconfined” name=“rapt” pid=684 comm=“apparmor_parser”
[ 26.123554] audit: type=1400 audit(1623062030.564:7): apparmor=“STATUS” operation=“profile_load” profile=“unconfined” name=“apt.systemd.daily” pid=685 comm=“apparmor_parser”
[ 26.126195] audit: type=1400 audit(1623062030.568:8): apparmor=“STATUS” operation=“profile_load” profile=“unconfined” name=“spice-vdagent” pid=678 comm=“apparmor_parser”
[ 26.126207] audit: type=1400 audit(1623062030.568:9): apparmor=“STATUS” operation=“profile_load” profile=“unconfined” name=“spice-vdagentd” pid=678 comm=“apparmor_parser”
[ 26.126519] audit: type=1400 audit(1623062030.568:10): apparmor=“STATUS” operation=“profile_load” profile=“unconfined” name=“/usr/bin/tor-circuit-established-check” pid=682 comm=“apparmor_parser”
[ 26.133117] audit: type=1400 audit(1623062030.572:11): apparmor=“STATUS” operation=“profile_load” profile=“unconfined” name=“/usr/bin/timesanitycheck” pid=681 comm=“apparmor_parser”
[ 26.137211] audit: type=1400 audit(1623062030.576:12): apparmor=“STATUS” operation=“profile_load” profile=“unconfined” name=“/usr/sbin/libvirtd” pid=683 comm=“apparmor_parser”
[ 26.137222] audit: type=1400 audit(1623062030.576:13): apparmor=“STATUS” operation=“profile_load” profile=“unconfined” name=“/usr/sbin/libvirtd//qemu_bridge_helper” pid=683 comm=“apparmor_parser”

I’m looking into the sdwdate issue so I can get it to work. I believe it’s an important feature of Kicksecure. I don’t see any denieds for sdwdate so I’m curious as to why it’s not working, perhaps a rule that denys the app from running within the apparmor profile?

Thanks,
sudobash

1 Like
83

sdwdate is not supposed to be run in terminal under user user. Maybe useful during development without AppArmor profile. But otherwise sdwdate’s AppArmor profile doesn’t support that. And if it did, it might weaken AppArmor protections. Dunno. Maybe with some HOME variable in sdwdate apparmor profile it might work. I think running sdwdate under user user was discussed earlier in these forums somewhere. I am not sure what I should be doing in such situations. Changing the clock requires root or a capability. Therefore running under user user seems not useful. To simulate sdwdate from command line:

sudo systemctl stop sdwdate
sudo -u sdwdate sdwdate

That circumvents systemd sandboxing.

Otherwise sudo systemctl restart sdwdate so it’s run through its systemd unit with apparmor proifle and its systemd sandboxing.

Useful to see this when users post logs with sdwdate so I can answer what I just answered. But not considered an sdwdate bug.

This also happens without AAE. Minuscule bug affecting log output only.

2 Likes