apparmor chromium profile blocks yubikeys

Bug #1825331 reported by Hadmut Danisch
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
apparmor (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Hi,

some months ago (can't give a precise date) I could use all my pure u2f tokens, as well as Yubikey tokens with mixed apps (yubikey 4, yubikey neo) pretty well with chromium browser as u2f tokens.

For some months now and since an update of the chromium-browser in 18.04, it was working with pure u2f tokens (e.g. the blue yubikeys, FIDO u2f token,...), but not with regular yubikeys anymore, although command line tools like u2f-host worked pretty well.

I checked the kernel messages and did not find any apparmor deny message or other reasons. Furthermore, the apparmor profile for usr.bin.chromium-browser was in complain mode only.

Now I did again some debugging and found that the problem is gone after

aa-disable usr.bin.chromium-browser

Although the profile was in complain mode and dmesg did not show any forbidden actions, the strace showed some EPERM (Operation not permitted) errors, that's why I tried to disable aa.

Interestingly, this problem does not affect regular u2f tokens, just the yubikeys with additional functions.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: apparmor-profiles 2.12-4ubuntu5.1
ProcVersionSignature: Ubuntu 4.15.0-47.50-generic 4.15.18
Uname: Linux 4.15.0-47-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.9-0ubuntu7.6
Architecture: amd64
CurrentDesktop: LXDE
Date: Thu Apr 18 11:14:22 2019
InstallationDate: Installed on 2018-04-30 (352 days ago)
InstallationMedia: Lubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
PackageArchitecture: all
ProcKernelCmdline: BOOT_IMAGE=/vmlinuz-4.15.0-47-generic root=UUID=5dca854b-2558-44a1-918d-c8380934754d ro nosplash
SourcePackage: apparmor
Syslog:

UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Hadmut Danisch (hadmut) wrote :
Revision history for this message
Christian Boltz (cboltz) wrote :

KernLog.txt contains several ALLOWED lines for chromium, and also DENIED lines for firefox (unrelated to this bugreport, but nevertheless we should probably check them.

You mentioned that you got some EPERM in strace - can you please tell us which files were affeted?

Wild guess: maybe those files were covered by "deny" rules in the firefox profile or an abstraction. (deny rules get enforced even in complain mode, and silence the logging.)

Revision history for this message
Hadmut Danisch (hadmut) wrote :

That's a long list of EPERMs in strace and mostly useless by itself, since chrome make use of nonblocking/asynchronous IO, so you always have to look for the syscall that had caused the EPERM. A full trace is rather huge.

In case you have a yubikey (not just a regular u2f oder blue yubikey, they don't show the problem) simply do something like

strace -s 80 -f -o chromiumyubitrace chromium-browser --temp-profile https://demo.yubico.com/u2f

Revision history for this message
jtl999 (jtl999) wrote :

I can reproduce this issue with an AppArmor profile in complain mode for both Firefox 67 and Chromium 74 on ubuntu 18.04

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in apparmor (Ubuntu):
status: New → Confirmed
Revision history for this message
Francesco Ponzin (francesco-ponzin) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.