snapd gives all users access to system logs

[Robert Ancell]

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)

[Jamie Strandboge (jdstrand)]

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.

[Jamie Strandboge (jdstrand)]

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)]

Gah!

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

[Jamie Strandboge (jdstrand)]

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"
}

[Jamie Strandboge (jdstrand)]

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)]

This has been assigned CVE-2017-14178.

[John Lenton (chipaca)]

https://github.com/snapcore/snapd/pull/4194

[John Lenton (chipaca)]

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)]

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

[Jamie Strandboge (jdstrand)]

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

[Jamie Strandboge (jdstrand)]

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.