[snap] apparmor denials on /etc/chromium-browser/policies/

Bug #1714244 reported by Olivier Tilloy
26
This bug affects 5 people
Affects Status Importance Assigned to Milestone
chromium-browser (Ubuntu)
Medium
Olivier Tilloy

Bug Description

[1565519.440403] audit: type=1400 audit(1504185084.568:68574811): apparmor="ALLOWED" operation="open" profile="snap.chromium.chromium" name="/etc/chromium-browser/policies/managed/" pid=19433 comm="chromium-browse" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

[1565519.440527] audit: type=1400 audit(1504185084.568:68574812): apparmor="ALLOWED" operation="open" profile="snap.chromium.chromium" name="/etc/chromium-browser/policies/recommended/" pid=19433 comm="chromium-browse" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

Those denials don't appear to prevent the app from running. Still, they should be investigated and fixed if possible.

Revision history for this message
Olivier Tilloy (osomon) wrote :

The code in chromium that determines where to look for policies is there: https://cs.chromium.org/chromium/src/chrome/common/chrome_paths.cc?l=482.

In the ubuntu packages this is being patched to "/etc/chromium-browser/policies/": http://bazaar.launchpad.net/~chromium-team/chromium-browser/artful-stable/view/head:/debian/patches/configuration-directory.patch.

That patch could be made $SNAP-aware.

That directory is meant for system-wide policies installed by sysadmins, not regular users. In that regard, there is little value in patching it to point to $SNAP/etc/chromium-browser/policies/, since that directory is not writeable.
There doesn't appear to be any way in chromium to disable the instantiation of the policy connector that queries those directories.

Revision history for this message
Olivier Tilloy (osomon) wrote :

Given that the denials are harmless and that getting rid of them would require a patch that wouldn't enable sysadmins to actually implement custom policies, I'll lower the importance of that bug.

Changed in chromium-browser (Ubuntu):
importance: Medium → Low
assignee: Olivier Tilloy (osomon) → nobody
Revision history for this message
Joachim Sauer (saua) wrote :

Is there a separate bug somewhere about actually implementing custom policies? Since 19.10 switched Chromium to Snap this means that not having those is an actual regression compared to 18.10 or 19.04, so I'd say this warrants a slightly higher priority now.

Revision history for this message
Olivier Tilloy (osomon) wrote :

@Joachim: there's no separate bug for this yet, but you're right that this needs attention. Would you mind filing one to track this separately? If you can attach examples of custom policies that would be great, too.

Revision history for this message
Olivier Tilloy (osomon) wrote :

A separate bug was filed: bug #1866732.

Revision history for this message
Oliver Grawert (ogra) wrote :

is there any particular reason to not simply adjust the patch to point to $SNAP_DATA/etc/chromium-browser/policies ? after all this is where system-wide configs should go ...

Revision history for this message
Olivier Tilloy (osomon) wrote :

You're right Oliver, the patch should be adjusted to look for policies in $SNAP_DATA.

Changed in chromium-browser (Ubuntu):
assignee: nobody → Olivier Tilloy (osomon)
importance: Low → Medium
Revision history for this message
Olivier Tilloy (osomon) wrote :

And for migration purposes, ideally the existing policies in /etc/chromium-browser/policies would be copied over to $SNAP_DATA/.

Revision history for this message
Damien Clabaut (dclabaut) wrote :

Is there any update or workaround on this issue? This is going to be a problem to everyone in enterprise environments.

Olivier Tilloy (osomon)
Changed in chromium-browser (Ubuntu):
status: Triaged → In Progress
Revision history for this message
Olivier Tilloy (osomon) wrote :
Changed in chromium-browser (Ubuntu):
status: In Progress → Fix Committed
Revision history for this message
Olivier Tilloy (osomon) wrote :

$SNAP_DATA/policies is not writable by the snap, so the import of existing policies won't work.
This would have to be implemented in the transitional deb package's postinst script.

What can be done is to try $SNAP_DATA/policies, and if that folder doesn't exist fall back to /etc/chromium-browser/policies.

Revision history for this message
Olivier Tilloy (osomon) wrote :
Revision history for this message
Ian Johnson (anonymouse67) wrote :

@osomon,

> $SNAP_DATA/policies is not writable by the snap, so the import of existing policies won't work.

$SNAP_DATA is by definition writable, so I'm curious what led you to think that it isn't? If it is showing up as read-only then that would be a snapd bug. Perhaps you were running as non-root, as the directory is root-owned and only writable by root ?

Revision history for this message
Olivier Tilloy (osomon) wrote :

@Ian, I meant that a snapped application, run as the current user, won't be able to write to its $SNAP_DATA. I just verified that with:

    snap run --shell chromium
    cd $SNAP_DATA
    touch foobar

and got "touch: cannot touch 'foobar': Permission denied"

Revision history for this message
Olivier Tilloy (osomon) wrote :
Revision history for this message
Jon Schewe (jpschewe) wrote :

Running Chromium Version 86.0.4240.111 (Official Build) snap (64-bit) on Ubuntu 20.04 and I'm not seeing my policies enforced inside Chromium.

Revision history for this message
Olivier Tilloy (osomon) wrote :

@Jon: are your policies in /etc/chromium-browser/policies ? Is there a symlink in that directory?

Revision history for this message
Peter Rowlett (prowlett) wrote :

@Olivier Thank you for working on this, but chromium policies do not appear to be working for me.

I have Chromium Version 86.0.4240.183 (Official Build) snap (64-bit) running on Ubuntu Budgie.

Following https://www.chromium.org/administrators/linux-quick-start to test if policies are being enforced I set up a policy test_policy.json which contains
{
  "HomepageLocation": "www.chromium.org"
}
I made this policy in /var/snap/chromium/current/policies/managed which I saw referenced in https://git.launchpad.net/~chromium-team/chromium-browser/+git/snap-from-source/commit/?id=6f2b87da50bce971f4baadae348331e1bd024cb8 but it did not work.

By "did not work", I mean when I restart chromium my homepage is not www.chromium.org.

Also I noticed that when I open chromium and go to chrome://policy it says HomepageLocation is set to
Policy Value: www.chromium.org
Source: Platform
Applies to: Machine
Level: Mandatory
Status: OK
Which seems fine, but then the homepage is not that so it seems the policy is not being applied.

Revision history for this message
Olivier Tilloy (osomon) wrote :

"HomepageLocation" has a bit of a misleading name. It defines only the page that is opened when clicking the homepage toolbar button, which isn't a thing anymore.

So what you really want to define is "RestoreOnStartupURLs" (https://www.chromium.org/administrators/policy-list-3#RestoreOnStartupURLs).

Revision history for this message
Peter Rowlett (prowlett) wrote :

@Olivier Ah, sorry, thank you for explaining this. This isn't what I want to do, I was just trying to strip back to the basics of what https://www.chromium.org/administrators/linux-quick-start said to do and demonstrate that it wasn't working.

I changed my policy so it says
{
  "RestoreOnStartupURLs": "www.chromium.org"
}

Now when I open chromium, it doesn't go to www.chromium.org. When I go to chrome://policy it reports RestoreOnStartupURLs has value www.chromium.org but says there is an error "Expected list value". I changed it to
{
  "RestoreOnStartupURLs": ["www.chromium.org"]
}
And it works. It is a shame the example code given on https://www.chromium.org/administrators/linux-quick-start doesn't function any more.

What got me to this point was trying to set
{
    "EnableMediaRouter": false
}
to stop chromium from monitoring network ports. Previously I couldn't get chromium to acknowledge a policy is set, but now I see I am able to set policy, but this one is not enforced. Still, I think this is a different problem to this thread. Thanks again!

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers