Clicking a hyperlink in a PDF fails to open it if the default browser is a snap

Note that this works with the evince snap, only the deb package is affected.

I can "fix" the issue if I add the following two lines to /etc/apparmor.d/abstractions/ubuntu-browsers and reload the evince profile:

  /usr/bin/env rmix,
  /usr/bin/snap Cx -> sanitized_helper,

Probably not acceptable as is because this would allow executing any snap, not just chromium. And snaps are not guaranteed to be strictly confined (e.g. classic/devmode).

But a rule on /snap/bin/chromium is not good enough as /snap/bin/chromium is a symlink to /usr/bin/snap.

I went through this the other day with a personal profile. We probably can do something along the lines of:

/{,snap/core/[0-9]*/}usr/bin/snap mrCx -> snap_browser,

profile snap_browser {
    #include <abstractions/base>

    /etc/passwd r,
    /etc/group r,
    /etc/nsswitch.conf r,
    /dev/tty rw,

    # noisy
    deny network inet stream,
    deny network inet6 stream,
    deny owner /run/user/[0-9]*/gdm/Xauthority r, # not needed on Ubuntu

    /{,snap/core/[0-9]*/}usr/bin/snap mrix, # re-exec
    /etc/fstab r,
    @{PROC}/sys/net/core/somaxconn r,
    @{PROC}/sys/kernel/seccomp/actions_avail r,
    owner @{PROC}/@{pid}/mountinfo r,
    owner @{HOME}/.snap/auth.json r, # if exists, required
    /run/snapd.socket rw,
    /snap/core/[0-9]*/usr/lib/snapd/info r,
    /snap/core/[0-9]*/usr/lib/snapd/snapd r,
    /var/lib/snapd/system-key r,

    /{,snap/core/*/}usr/lib/snapd/snap-confine Pix,
    /sys/kernel/security/apparmor/features/ r,

    # allow launching official browser snaps. This could be abstracted into an #include or tunable
    /snap/chromium/*/meta/snap.yaml r,
    /snap/firefox/*/meta/snap.yaml r,
    # ...
  }

@Jamie, given your recent work on the evince apparmor profile, should that be assigned to you?

After transition to snap the Chromium is not usable for me. I have a lot of PDFs with hyperlinks and they stopped working. Is there any workaround other then migrating to deb Chrome?

This has come up again, now that the default browser in impish is the firefox snap (see https://discourse.ubuntu.com/t/feature-freeze-exception-seeding-the-official-firefox-snap-in-ubuntu-desktop/24210/107).

Jamie, I assume this should be unassigned, as you're not actively working on this, are you?

Status changed to 'Confirmed' because the bug affects multiple users.

Also I'm not sure I agree with jdstrand's apparmor profile which includes:

    /run/snapd.socket rw,

which I don't think we want to grant to any PDF file opened with evince?

Olivier, yes, I shouldn't be assigned. Ian, you're right the profile is suboptimal (it's also old so likely needs updating).

Do note that this is a separate named profile and evince (and if this is put in an abstraction, anything that uses the abstraction) only has the `/{,snap/core/[0-9]*/}usr/bin/snap mrCx -> snap_browser,` rule which means that it is able to run the 'snap' command (needed since everything in /snap/bin points to /usr/bin/snap) which at the time I wrote the profile meant that access to this socket was needed as part of snap run. IIRC, snapd should be protecting certain actions by uid connecting to it (eg, you are root or not), but it has been a while since I've looked at that. Evince is not a snap though so if snapd does any checks on 'is the client a snap' then those would fail and evince would be able to do whatever a non-root user could do with the 'snap' command via the socket.

For snap run, we can see that the snap_browser profile limits what can be used with 'run' since (at the time I wrote the comment) 'snap run' required being able to look at the meta/snap.yaml of the specific snap. This 'works' (worked?) but is brittle since if snap run changed to lift this requirement (eg, 'snap run' just passed the name of the unresolved symlink to snapd over the socket and let snapd start the snap, perhaps via userd, etc) then this falls apart.

The profile was put up as an example as what could be done at the time without any help from snapd. I never particularly cared for it cause it was brittle and not designed. I'm not sure how to fix this, but here are some thoughts:
* evince is just executing stuff from /snap/bin (probably via the system's xdg-open). Assuming xdg-open, the system's xdg-open (or whatever evince is using to decide and launch the default browser) could itself be fixed in Ubuntu to launch a different command that behaved better. This wouldn't necessarily fix other distros (though this is the evince profile in Debian and Ubuntu, so *technically*, if you got this change (to presumably xdg-open) into them, you could update the evince profile in them accordingly)
* In lieu of that, if the profile still worked as intended, snapd could be hardened to look to check more than if the connecting process is root or a snap; it could also see if it is running under a non-snap profile, then limit access to the socket API accordingly. This has drawbacks and could break people who have written custom profiles similar to what I presented.
* I suppose an alternative approach would be to have symlinks in /snap/bin for things that are registered as browsers (or just the default browser) point to a designed snap command. Eg:

  /snap/bin/firefox -> /usr/bin/snap # keep the existing one too
  /snap/bin/default-browser-is-a-snap -> /usr/bin/snap-browser # name is illustrative, TBD

  Now firefox, chromium, opera, brave, etc snaps registers themselves as being capable of being a default browser with snapd, then snapd registers with the system that /snap/bin/default-browser-is-a-snap is the default browser (so system utilities like xdg-open don't need to change) and /usr/bin/snap-browser is written to be saf...

I was able to reproduce this issue on focal and bionic but not on impish. I'm still investigating why, since I don't see any changes in policies that might affect this issue, but I could have missed something.

Is there any option to do this via portals - ie can evince use https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.OpenURI to open the URI? Would then this allow to avoid going via xdg-open?

I pulled the evince source and there does not appear to be any direct support for portals, and sandbox support is an untasked item on their roadmap. However it still may be possible via the gnome libs, or via dlopen. Those routes would need to be further investigated.

I'm running Jammy, upgraded from Focal, and this bug bites me:
(evince:56279): dbind-WARNING **: 12:05:26.897: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/1000/at-spi/bus: Permission denied

... then /var/log/syslog:
[...] audit: type=1400 audit(1649153341.153:384): apparmor="DENIED" operation="exec" profile="/usr/bin/evince" name="/usr/bin/snap" pid=56653 comm="env" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

> Is there any option to do this via portals - ie can evince use
> org.freedesktop.portal.OpenURI to open the URI? Would then this
> allow to avoid going via xdg-open?

Evince is using g_app_info_launch_default_for_uri(), which can use the portal interface:

https://gitlab.gnome.org/GNOME/evince/-/blob/main/shell/ev-window.c#L6775-6778

However, it only does this as a fallback if no desktop file supports the URI. This is intended to allow a confined app to handle some file types within the sandbox before falling back to portals for everything else.

In the case of Evince running on the host system and seeing all the desktop files in /usr/share/applications and other locations, it likely won't ever call the portal API.

It'd be possible to code in explicit portal API calls, but it isn't something that Evince packaged as a flatpak or snap would need. So it might end up as a distro patch we'd be on the hook to maintain forever.

it sounds like something that we should fix one way or another at least for the LTS, maybe in the futur we will have evince as a snap instead and the situation will be different. Could you suggest a patch for review with the change you described?

I'm working on a SRU for apparmor and evince to introduce the snap_browsers abstraction on apparmor as a workaround for this issue.
It is based on these two merge requests from upstream:
https://gitlab.com/apparmor/apparmor/-/merge_requests/806
https://gitlab.com/apparmor/apparmor/-/merge_requests/877

@Georgia, great, should we assign the apparmor line of the bug to you?

@Sebastien, yes, just did. Thank you!

I also attached the debdiffs for evince and apparmor for bionic, focal, impish and jammy. They were also uploaded into the Security Proposed PPA:
https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages?field.name_filter=apparmor
https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages?field.name_filter=evince

@Georgia, thanks for the work! Is anyone from the security team going to sponsor the apparmor updates for you?

Also in the evince debdiff, you added apparmor to the Build-Depends but is that needed? If the intend is to ensure a recent enough apparmor is available on the sytem then the Depends should be enough?

Also evince didn't depends on apparmor before, it's probably fine to change that but I still want to raise the question. What would be the outcome of installing the new evince with an old apparmor? would the missing rules just be ignored or would they create issues?

@Sebastien, yes, I asked people from the security team to sponsor it but we are still reviewing the snap_browsers abstraction. We are denying access to /run/user/[0-9]*/gdm/Xauthority in the policy but if that was the case, then the browser should not have been able to open, but it does open so we are investigating if there's an issue.

Regarding the evince debdiff, even though it looks like the dependency is on Build-Depends on the debdiff, it is actually under Depends. If we don't set this dependency, then the snap_browsers abstraction might not be available. So if the new evince is installed with an old apparmor, then the evince apparmor policy will fail to load and evince will run unconfined.

@georgiag we could move the abstraction include to "include if exists" to take care of the depends. Generally speaking evince shouldn't depend on apparmor, but of course make use of it if it is available.

Status changed to 'Confirmed' because the bug affects multiple users.

I made some changes to the patches I submitted previously. In summary, I added permission to Xauthority files in the AppArmor abstraction and changed the dependency of AppArmor in Evince to "Recommends".
Please let me know if it looks okay or if there's any changes I should do
They are in
https://launchpad.net/~georgiag/+archive/ubuntu/test3/+packages

@georgia so the usual process (as per https://wiki.ubuntu.com/StableReleaseUpdates) from here would be to first get the changes into apparmor/evince in the current devel release (kinetic) and once it is verified that they are working fine there, then we backport them to jammy etc.

Still broken, 17th September 2022 in Ubuntu 22.04.
Evince prints the following message "env: ‘/snap/bin/firefox’: Permission denied"
Workaround: https://github.com/popey/unsnap

Is there any update on the issue?

The bug still exist on Kinetic.

Still here in 22.04 LTS; the workaround I use is the last one suggested in https://askubuntu.com/a/1428798/16395 (WARNING; that will allow evince to launch *any* snap in your system. But otherwise, evince is severely limited...)

Can someone provide a reference PDF showing this issue, to use in the SRU verification? (They are common, but we shouldn't have to hunt for one for the verification)

Found one locally that doesn't contain any confidential information, so attaching

Georgia, as noted in comment #31, it's better to use '#include if exists' than to add a versioned dependency on apparmor. Can you update the patches to do this and verify that it works as expected? Once this is done please resubscribe ~ubuntu-sponsors and we can get this done.

Here is one made for the very purpose of (not) being clickable.

Hi Steve.
I updated the patches containing the requested changes and uploaded them to
https://launchpad.net/~georgiag/+archive/ubuntu/lp1794064/+packages
Please let me know if you prefer I attached the debdiffs here.

I'm resubscribing ~ubuntu-sponsors. Thanks

This bug was fixed in the package evince - 44.1-1ubuntu1

---------------
evince (44.1-1ubuntu1) mantic; urgency=medium

  * Allow evince to spawn browsers distributed as snaps (LP: #1794064)
    - debian/apparmor-profile: include snap-browsers abstracted profile
      and allow transitions to them in evince

 -- Georgia Garcia <email address hidden> Mon, 05 Jun 2023 16:35:51 -0300

I see that there is an apparmor upload for this bug in the lunar queue, in addition to the evince upload. The apparmor upload adds a line to abstractions/snap_browsers. This bug report does not explain that the abstractions/snap_browsers was previously inadequate or that it should be updated to fix this bug. Please provide more information of why this apparmor change is needed.

Hello Olivier, or anyone else affected,

Accepted evince into lunar-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/evince/44.1-1ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-lunar to verification-done-lunar. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-lunar. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Hello Olivier, or anyone else affected,

Accepted apparmor into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/apparmor/3.0.4-2ubuntu2.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

The evince upload to jammy still does:

+Recommends: default-dbus-session-bus | dbus-session-bus,
+ apparmor (>= 3.0.4-2ubuntu2.3),

with the explanation that:

+ - debian/control.in: recommend apparmor version that includes the
+ snap_browsers abstraction, or else policy loads will fail.

But the use of #include if exists was supposed to make this unnecessary. And downgrading the Depends to a Recommends doesn't change the default behavior here; installing this version of evince will by default pull in apparmor, even in contexts where apparmor was not previously installed. (There are not many of those in Ubuntu, which means if apparmor was not installed it was probably deliberate on the part of the admin!)

I'm rejecting this upload, as to my understanding this is not what we're meant to have.

An upload of evince to jammy-proposed has been rejected from the upload queue for the following reason: "adds Recommends that shouldn't be needed".

All autopkgtests for the newly accepted apparmor (3.0.4-2ubuntu2.3) for jammy have finished running.
The following regressions have been reported in tests triggered by the package:

dbus/1.12.20-2ubuntu4.1 (armhf)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/jammy/update_excuses.html#apparmor

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

This bug was fixed in the package apparmor - 3.0.8-1ubuntu3

---------------
apparmor (3.0.8-1ubuntu3) mantic; urgency=medium

  * Update abstractions/snap-browsers to include lock permissions
    (LP: #1794064)
    - d/p/u/update-snap-browsers-permissions-lp1794064.patch

 -- Georgia Garcia <email address hidden> Tue, 06 Jun 2023 08:52:13 -0300

Steve, the snap_browsers abstractions needed an update because the abstraction had not been updated in an year and the snap browsers now required read and lock permissions to the file /var/lib/snapd/inhibit/{browser-name}.lock, but this was also submitted, approved and merged upstream: https://gitlab.com/apparmor/apparmor/-/merge_requests/1045

Regarding the patch for evince, I kept the "Recommends" because, yes, the include if exists checks if the abstraction is present and it only includes in the case it is, but the actual rule which references the snap_browsers profile could fail for apparmor versions for which snap_browsers does not exist.
/{,snap/core/[0-9]*/,snap/snapd/[0-9]*/}usr/bin/snap mrCx -> snap_browsers,

I have confirmed that the updated evince, without an updated apparmor, fails in lunar with this error on stderr from evince:

internal error, please report: running "chromium" failed: open /var/lib/snapd/inhibit/chromium.lock: permission denied

that looks sufficient to me to move forward with this SRU, with the existing test case.

Hello Olivier, or anyone else affected,

Accepted apparmor into lunar-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/apparmor/3.0.8-1ubuntu2.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-lunar to verification-done-lunar. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-lunar. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

I have verified on lunar with both apparmor and evince packages updated from the proposed pocket, it works as expected.

evince and apparmor for lunar should be released together to fix this bug, but there is still a DEP8 failure that needs clearing under apparmor: libreoffice/armhf

https://ubuntu-archive-team.ubuntu.com/proposed-migration/lunar/update_excuses.html#apparmor

It was retried a few times already, but still fails. This is a very long test, 5-6h, andlibreoffice/armhf is already in the big_packages DEP8 queue, which gives it a bigger VM.

I triggered it one more time.

Ah, and besides that, apparmor has been in proposed for just 5 days, not the required 7.

The autopkgtest passed for apparmor lunar libreoffice/armhf

Do we need evince to be reuploaded for jammy there since the previous upload was rejected by Steve?

This bug was fixed in the package apparmor - 3.0.8-1ubuntu2.1

---------------
apparmor (3.0.8-1ubuntu2.1) lunar; urgency=medium

  * Update abstractions/snap-browsers to include lock permissions
    (LP: #1794064)
    - d/p/u/update-snap-browsers-permissions-lp1794064.patch

 -- Georgia Garcia <email address hidden> Tue, 06 Jun 2023 08:49:17 -0300

The verification of the Stable Release Update for apparmor has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

> Do we need evince to be reuploaded for jammy there since the previous upload was rejected by Steve?

I'm trying to see what type of error we get if we load a profile with such a rule and the target profile does not exist:

  /{,snap/core/[0-9]*/,snap/snapd/[0-9]*/}usr/bin/snap mrCx -> snap_browsers,

Will it be worse than what we have now?
Will evince's postinst fail when it reloads the profile with the above line, and snap_browsers is not defined?
Will it crash when a link in a pdf is clicked?

It's taking a bit to setup a jammy desktop vm to try this, and I have other SRUs to process. Georgia, could you elaborate on what would happen if the new evince were to be installed with an old apparmor that knows nothing about the snap_browsers profile?

Andreas, Debian Testing right now has the updated evince but not the updated apparmor. https://bugs.debian.org/1040481

The consequence is that hyperlinks from Evince don't open if the default browser is a Snap. That's the same consequence as before the Evince change.

Looks like we get this if evince is update, apparmor is not, and a link in a pdf is clicked:

Jul 06 18:36:59 j-evince kernel: audit: type=1400 audit(1688668619.304:78): apparmor="DENIED" operation="exec" info="profile transition not found" error=-13 profile="/usr/bin/evince" name="/usr/bin/snap" pid=2246 comm="env" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

The end result seems the same: permission denied, link isn't opened, the evince gui just does nothing, the console (if launched from a terminal) saya "env: '/snap/bin/firefox': Permission denied

If Georgia can confirm this is the worst that can happen by not having the Recommends on the updated apparmor profile, then I think it's ok to leave it out, but would be good to have confirmation from @vorlon, as he raised the objection and it's not clear if he saw Georgia's comment.

Andreas, Jeremy, you are correct. The worst that could happen is the same behavior we have currently: when we click a URL the browser does not open, we get a denied log and evince prints "Permission denied".

My previous statement that profile loading could fail if apparmor did not find "snap_browsers" was a mistake. Evince installs successfully and apparmor loads the evince policy correctly. The apparmor service also does not fail if restarted.

I updated the evince package for jammy removing the "Recommends" in the ppa I shared previously if needed:
https://launchpad.net/~georgiag/+archive/ubuntu/lp1794064/+packages

Thank you all and I'm sorry for the confusion.

This bug was fixed in the package evince - 44.1-1ubuntu0.1

---------------
evince (44.1-1ubuntu0.1) lunar; urgency=medium

  * Allow evince to spawn browsers distributed as snaps (LP: #1794064)
    - debian/apparmor-profile: include snap-browsers abstracted profile
      and allow transitions to them in evince

 -- Georgia Garcia <email address hidden> Mon, 05 Jun 2023 16:32:15 -0300

Apparmor in jammy-proposed has the necessary changes, we just need a new evince upload to jammy without the recommends then.

Hi Georgia, is this still pending an evince fix? Your PPA has an updated evince package, but I don't think it was uploaded to unapproved yet, without the recommends.

Hi! You're right, I forgot to request a sponsorship.

I uploaded the patch for evince/jammy, could you take a look and sponsor if possible? Thanks