snapd gives all users access to system logs

Bug #1730255 reported by Robert Ancell on 2017-11-06
260
This bug affects 1 person
Affects Status Importance Assigned to Milestone
snapd
Undecided
John Lenton
snapd (Ubuntu)
Undecided
Unassigned
Trusty
Undecided
Unassigned
Xenial
Undecided
Unassigned
Zesty
Undecided
Unassigned
Artful
Undecided
Unassigned
Bionic
Undecided
Unassigned

Bug Description

Using the /v2/logs REST API call any user can access system logs, i.e.:

$ journalctl
Hint: You are currently not seeing messages from other users and the system.
      Users in the 'systemd-journal' group can see all messages. Pass -q to
      turn off this notice.
No journal files were opened due to insufficient permissions.

$ curl -s --unix-socket /run/snapd.socket http://localhost/v2/logs|jq
{
  "timestamp": "2017-11-05T23:59:33.694335Z",
  "message": "pam_unix(polkit-1:session): session opened for user root by (uid=1000)",
  "sid": "pkexec",
  "pid": "29512"
}

This was introduced in (snapd 2.27):

commit 85331c16dd76eb14fcfe0cdcbd5603b4fcd802e4
Author: John Lenton <email address hidden>
Date: Thu Aug 3 17:09:34 2017 +0100

    many: implement "snap logs" (#3630)

    * many: implement "snap logs"

    * cmd/snap: drop ineffectual assignment (ouch)

    * systemd: drop unused methods from Log; add tests for Log.Time

    * many: address review feedback (mostly "d’oh"; thanks zyga!)

    * address review feedback (thanks pedronis)

CVE References

Jamie Strandboge (jdstrand) wrote :

Thanks for the report!

John, can you take a look at this? I think you need to lookup the user/group from the cred on the socket and verify the user has the permissions to view the logs.

I've tentatively assigned this to John, but please feel free to reassign. I think this needs a CVE. Please don't discuss in public or make public commits until the security team comments further on this bug.

Changed in snapd (Ubuntu):
assignee: nobody → John Lenton (chipaca)
Jamie Strandboge (jdstrand) wrote :

I discussed this with the security team and mvo and we decided that this will be assign 'low' priority in terms of the CVE, but that the fix should be in 2.29. Because it is 'low' priority, we can forego embargo and let the snapd team work and discuss this issue in public as they see fit.

It does mean that the 2.29 SRU will need to be built in the security ppa and get a USN. The timing can still be controlled by the SRU process though. Eg, give me the source package, I sponsor it into the security ppa, when built, we copy it to -proposed to undergo normal validation, when validated, it goes to both -updates and -security, when to -security, we issue the USN.

John Lenton (chipaca) wrote :

Gah!

Note this happens when you have no snaps with services installed :-(

Jamie Strandboge (jdstrand) wrote :

I can confirm this btw:

$ id
uid=1001(jamie-test) gid=1001(jamie-test) groups=1001(jamie-test)

$ journalctl
Hint: You are currently not seeing messages from other users and the system.
      Users in the 'systemd-journal' group can see all messages. Pass -q to
      turn off this notice.
No journal files were opened due to insufficient permissions.

$ curl -s --unix-socket /run/snapd.socket http://localhost/v2/logs|jq
{
  "timestamp": "2017-11-09T13:00:10.409213Z",
  "message": "UDEV [47902.395905] remove /kernel/slab/:t-0000512/cgroup/kmalloc-512(5427:snap-repair.service) (cgroup)",
  "sid": "test-udevadm.udevadm-monitor",
  "pid": "4375"
}

Changed in snapd (Ubuntu):
status: New → Triaged
Changed in snapd (Ubuntu Trusty):
status: New → Triaged
Changed in snapd (Ubuntu Xenial):
status: New → Triaged
Changed in snapd (Ubuntu Zesty):
status: New → Triaged
Changed in snapd (Ubuntu Artful):
status: New → Triaged
Changed in snapd:
status: New → Triaged
assignee: nobody → John Lenton (chipaca)
Changed in snapd (Ubuntu Bionic):
assignee: John Lenton (chipaca) → nobody
Jamie Strandboge (jdstrand) wrote :

Thinking of cross-distro, IMO the snapd team should help distros that have 2.27 update to the fixed 2.29 with high priority when you deem it is ready.

Emily Ratliff (emilyr) wrote :

This has been assigned CVE-2017-14178.

John Lenton (chipaca) wrote :

This is assuming that showing *snap service* logs to all users is OK. If that's not the case, we can make logs require auth.

John Lenton (chipaca) wrote :

PR updated to make logs require admin, after some discussion on IRC.

John Lenton (chipaca) on 2017-11-09
Changed in snapd:
status: Triaged → In Progress
John Lenton (chipaca) on 2017-11-09
Changed in snapd:
status: In Progress → Fix Committed
Jamie Strandboge (jdstrand) wrote :

This was fixed in 2.29.3 upstream and 2.29.4.2 in all Ubuntu releases.

Changed in snapd:
status: Fix Committed → Fix Released
Changed in snapd (Ubuntu):
status: Triaged → Fix Released
Changed in snapd (Ubuntu Trusty):
status: Triaged → Fix Released
Changed in snapd (Ubuntu Xenial):
status: Triaged → Fix Released
Changed in snapd (Ubuntu Zesty):
status: Triaged → Fix Released
Changed in snapd (Ubuntu Artful):
status: Triaged → Fix Released
Jamie Strandboge (jdstrand) wrote :

Unfortunately because of the problems surrounding the 2.29 snapd release, the snapd package was not built in the security ppa so no USN was issued. Now that 2.30 and 2.31 snapd SRUs are happening and because this is a 'low' issue, we'll forego the USN. We want to improve our process going forward however to make sure security issues in snapd get USNs.

information type: Private Security → Public Security
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers