ssh-agent failing

[rndmc12]

Hi, I'm using your profiles on Arch with Gnome/standard kernel. The ssh-agent kept failing for me. ssh never returns in a user session and sends gnome-keyring-manager racing its thread, 100% reproducible here. The profile need a capability for ssh to work as intended. Adding:

/etc/apparmor.d/local/ssh-agent
 # Capabilities
  capability mknod,

resolves it.

The relevant aa-complain I derived it from is:

audit[5363]: AVC apparmor="ALLOWED" operation="mknod" profile="ssh-agent" name="/run/user/1000/keyring/.ssh" pid=5363 comm="ssh-agent" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
kernel: audit: type=1400 audit(1673261292.846:445): apparmor="ALLOWED" operation="mknod" profile="ssh-agent" name="/run/user/1000/keyring/.ssh" pid=5363 comm="ssh-agent" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000

BR

[nobody43]

I think that would be over-excessive. This line should fix the issue:

/{,var/}run/user/[0-9]*/keyring/.ssh rw,

[krathalan]

@rndmc12 please let me know if nobody43's line fixes the issue and I will add it to the profile.

[rndmc12]

Thanks for the comments. With nobody43's line gnome-keyring-daemon fails, being denied to bind to the keyring path in /run and starts to race again. Interestingly, after I kill the racing process once, it directly works on the next tests without further issue until reboot. Killing did not work-around with the original profile. I still have to look into it more later.

[rndmc12]

I now tried the current profile on a box without gnome-keyring-daemon and all seems fine. So, it should not be necessary to add to the existing ssh-agent profile, but the gnome package may need one (or there is a bug/config error with the default package).

I will comment again once I looked into that and just use above as work-around for the time being. You're welcome to close this issue meanwhile, if you want to.

[rndmc12]

I now checked why gnome-keyring-daemon starts at all. The point is that the Arch package defaults to not using --components=ssh. Hence, I assumed (following gnome-doc) it should not kick in for ssh anyway. It turns out that assumption is wrong. First, the corresponding /etc/xdg/autostart/gnome-keyring-ssh.desktop file needs to be deactivated for the system, or in the user's ~/.config/autostart/, by adding [Hidden]=true to the end of it. Then, there is a per-default enabled systemctl --user status gcr-ssh-agent.socket. If this is not disabled, it will race instead of the already hidden gnome-keyring-ssh with an apparmor enforce of the ssh-agent. Once both are disabled, the regular ssh-agent starts without issue.

I checked that both, the gnome ssh .desktop and .socket files, are packaged and default enabled by gnome-nightly upstream, regardless of --components=ssh being enabled or not.

So, it appears not to be neither a bug of these profiles, or an Arch bug. Since it is possible to disable the undesirable gnome-keyring behaviour for ssh, I close this issue. Btw, I also have not noticed other gnome-keyring problems while running apparmor.

HTH

[sandwm]

On my system, with gnome-keyring installed (and not disabled) and unchanged ssh-agent profile, trying to login via ssh hangs, gnome-keyring-daemon goes to 100% CPU load and I get:

gnome-keyring-daemon[2303]: unix_listener: cannot bind to path /run/user/1000/keyring/.ssh: Permission denied
kernel: audit: type=1400 audit(1685714244.300:132): apparmor="DENIED" operation="mknod" class="file" profile="ssh-agent" name="/run/user/1000/keyring/.ssh" pid=2303 comm="ssh-agent" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000

With this rule everything works:

owner /run/user/*/keyring/.ssh w,

In particular it works after a reboot. I don't know why it didn't for @rndmc12 on Jan 10, but on the other hand, either gnome-keyring / apparmor is behaving a bit weird (on my system?) or I handled apparmor_parser / ... wrong. In the end I resorted to apparmor_parser --purge-cache and reboot to test changes. (I have write-cache enabled in /etc/apparmor/parser.conf, but the cache file in /var/cache/apparmor/ apparently wasn't updated after renaming local/ssh-agent to local/ssh-agent.bak for testing.)

So the above rule (or the more permissive one by @nobody43) might not fix the issue in all cases, but since it seems to do so at least in some cases, is in-scope for ssh-agent (seems to be an ssh-agent unix socket) and (hopefully) shouldn't break things, I would add it to the default ssh-agent profile.

Edit: Regarding the issues with the cache, this might have been the culprit (from apparmor_parser(8)):

       -T, --skip-read-cache
           By default, if a profile's cache is found in the location specified by --cache-loc and the timestamp is newer than
           the profile, it will be loaded from the cache. This option disables this cache loading behavior.

       -W, --write-cache
           Write out cached profiles to the location specified in --cache-loc.  Off by default. In cases where abstractions have
           been changed, and the parser is running with "--replace", it may make sense to also use "--skip-read-cache" with the
           "--write-cache" option.