Public bug reported:
Summary
A single Chromium Snap desktop session using a fresh profile failed to navigate
to a private HTTPS page with net::ERR_ACCESS_DENIED. Existing kernel audit
records contain three nearby receive denials under snap.chromium.chromium
involving the loopback SOCKS proxy. The specific defect has not been
identified. This report describes correlation, not a proven causal chain or a
confirmed reproducible bug.
Software versions observed
- Ubuntu 24.04.4 LTS
- Kernel: 6.17.0-1021-nvidia
- Chromium Snap: 155.0.8059.79, revision 3560, latest/stable, publisher
Canonical
- snapd: 2.77.1
- AppArmor parser: 4.0.1
- Ubuntu apparmor/libapparmor1 package version:
4.0.1really4.0.1-0ubuntu0.24.04.7
Existing proxy relationship
The desktop GNOME proxy settings observed after the failure were:
org.gnome.system.proxy mode = 'manual'
org.gnome.system.proxy.socks host = '127.0.0.1'
org.gnome.system.proxy.socks port = 10889
org.gnome.system.proxy ignore-hosts = ['localhost', '127.0.0.1', '::1']
org.gnome.system.proxy use-same-proxy = true
The HTTP and HTTPS proxy host fields were empty.
127.0.0.1:10889 is an existing OpenSSH dynamic SOCKS listener, managed by an
enabled, active user-level systemd service. Its relevant command structure is:
/usr/bin/ssh -N [authentication and connection options omitted] -D
127.0.0.1:10889 <REDACTED_REMOTE_ENDPOINT>
The listener predated this browser session. No proxy override was present in
the browser launch arguments. These observations support inheritance of desktop
proxy settings, but no per-request proxy-resolution trace was captured.
Sanitized launch arguments (historical record, not a request to reproduce)
/snap/bin/chromium
--user-data-dir=<FRESH_TEMP_PROFILE>
--host-resolver-rules="MAP <PRIVATE_HOST> <PRIVATE_IP>"
--remote-debugging-pipe
--no-first-run
--no-default-browser-check
--disable-background-networking
--window-size=1280,960
about:blank
After startup, CDP Page.navigate requested the private HTTPS page. The
hostname mapping was limited to this browser session. Chromium
sandboxing and normal HTTPS certificate verification were retained. No
ignore-certificate-errors or no-sandbox flag was used.
Actual CDP failure excerpts (identifiers and destination removed)
Network.loadingFailed:
{"requestId":"<REQUEST_A>","type":"Document","errorText":"net::ERR_ACCESS_DENIED","canceled":false}
Page.navigate result:
{"frameId":"<FRAME_A>","loaderId":"<REQUEST_A>","errorText":"net::ERR_ACCESS_DENIED","isDownload":false}
Three related kernel audit excerpts
Absolute timestamps, audit serials and the task ID are redacted. <TASK_A>
consistently denotes the same observed task. The two occurrences using source
port 48964 were separate original audit entries, not duplicate copying. Entry C
followed A/B by approximately 4 ms.
A: apparmor="DENIED" operation="file_perm" class="net"
profile="snap.chromium.chromium" pid=<TASK_A> comm="Chrome_ChildIOT"
laddr=127.0.0.1 lport=48964 faddr=127.0.0.1 fport=10889 family="inet"
sock_type="stream" protocol=6 requested="receive" denied="receive"
B: apparmor="DENIED" operation="file_perm" class="net"
profile="snap.chromium.chromium" pid=<TASK_A> comm="Chrome_ChildIOT"
laddr=127.0.0.1 lport=48964 faddr=127.0.0.1 fport=10889 family="inet"
sock_type="stream" protocol=6 requested="receive" denied="receive"
C: apparmor="DENIED" operation="file_perm" class="net"
profile="snap.chromium.chromium" pid=<TASK_A> comm="Chrome_ChildIOT"
laddr=127.0.0.1 lport=48976 faddr=127.0.0.1 fport=10889 family="inet"
sock_type="stream" protocol=6 requested="receive" denied="receive"
Evidence limits and request
The audit records and browser launch used the same boot session. Journal
monotonic timestamps place the first network denial about 94 ms before the CDP
loading failure. However, NetLog and a complete child-process/thread
association were not captured. We cannot associate each denied socket with a
particular URL or establish that these denials were the sole cause. No
successful application response or browser TLS verification result was recorded.
The existing chromium:network interface was connected. Read-only
preprocessing of the on-disk snap.chromium.chromium profile included
network inet stream permission; this does not prove the exact compiled
policy loaded in the kernel. Reading the complete loaded-policy list was
denied to the unprivileged account.
The browser session was closed normally, with no download produced. It
has not been restarted or retried for this report. No system-level
security, proxy, DNS or network configuration was changed during the
browser attempt or this investigation.
Please advise whether this software combination has a known Chromium
Snap/AppArmor policy-loading or compatibility issue, and which minimal,
privacy-preserving read-only evidence would distinguish it from another
cause. A supported correction is requested only after the responsible
component is established.
Privacy
This text is prepared for a public issue. Private usernames, host/device
identifiers, boot ID, real private hostname/IP, business URL, private paths,
remote SSH endpoint, credentials and application data have been removed.
Placeholder values are not executable reproduction inputs. No full logs,
configuration files or project archive are attached.
** Affects: chromium-browser (Ubuntu)
Importance: Undecided
Status: New
** Tags: snap
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2171566
Title:
[snap] ERR_ACCESS_DENIED with GNOME SOCKS settings and nearby AppArmor
receive denials
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/2171566/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
