On Thu, 2020-06-18 at 03:00:35 +0930, Marc Deslauriers wrote: > On 2020-06-16 8:40 p.m., Matthew Ruffell wrote: >> Hello! >> >> I am proposing that we enable the CONFIG_SECURITY_DMESG_RESTRICT [1] feature >> by >> default for Groovy onward. >>
This sounds like a great (and long overdue) addition - thanks for investigating this Matthew! >> I wish to propose that we restrict /bin/dmesg to users within the 'adm' group >> only, which will have little visible impact to end users, while closing the >> final security gap currently enjoyed by unprivileged users on multiuser >> systems. >> >> The kernel log buffer is a treasure trove of sensitive information, and we >> give >> it out freely to anyone who asks for it. There have been substantial efforts >> upstream to reduce and prevent kernel addresses from being leaked, and usage >> of >> printk with '%p' have largely been removed. This is not enough, as if a >> system >> has suffered an oops, it still outputs functions, their offsets and >> addresses, >> and particularly, the contents of the stack, which usually contains kernel >> addresses. >> >> Exploit developers and attackers can leverage these information leaks to >> get past KASLR, and they can use the kernel log buffer to get instant >> feedback >> on their privilege escalation attacks, as failures will be shown as further >> oops >> messages, which attackers can use to fix and tune their programs until >> they work. >> >> Currently, if I create a new, unprivileged user on a Focal system, they >> cannot >> access /var/log/kern.log, /var/log/syslog or see system events in journalctl. >> But yet, they are given free reign to the kernel log buffer. >> >> $ sudo adduser dave >> $ su dave >> $ groups >> dave >> $ cat /var/log/kern.log >> cat: /var/log/kern.log: Permission denied >> $ cat /var/log/syslog >> cat: /var/log/syslog: Permission denied >> $ journalctl >> Hint: You are currently not seeing messages from other users and the system. >> Users in groups 'adm', 'systemd-journal' can see all messages. >> Pass -q to turn off this notice. >> Jun 16 23:44:59 ubuntu systemd[2328]: Reached target Main User Target. >> Jun 16 23:44:59 ubuntu systemd[2328]: Startup finished in 69ms. >> $ dmesg >> [ 0.000000] Linux version 5.4.0-34-generic (buildd@lcy01-amd64-014) >> (gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)) #38-Ubuntu SMP Mon May 25 >> 15:46:55 >> UTC 2020 (Ubuntu 5.4.0-34.38-generic 5.4.41) >> [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.4.0-34-generic >> root=UUID=f9f909c3-782a-43c2-a59d-c789656b4188 ro >> ... >> >> Why should users have access to dmesg if they can't access /var/log/kern.log? >> >> I propose that we restrict access to dmesg to users in group 'adm' like so: >> >> 1) CONFIG_SECURITY_DMESG_RESTRICT=y in the kernel. >> 2) Following changes to /bin/dmesg permissions in package 'util-linux' >> - Ownership changes to root:adm >> - Permissions changed to 0750 (-rwxr-x---) >> - Add cap_syslog capability to binary. >> 3) Add a commented out '# kernel.dmesg_restrict = 0' to >> /etc/sysctl.d/10-kernel-hardening.conf This sounds like a nice and effective way of achieving this - plus since we now have journald and journalctl (used by gnome-logs and others) this matches the behaviour seen there as well. +1 from me! >> >> For most users, they will use the initial admin account, which is in the >> 'adm' >> group already, and will see no impact to these changes. If a log scraper type >> program needs access to dmesg, the user the daemon runs as can simply be >> added >> to the 'adm' group. >> >> You can try the proposed changes at home, right now with: >> >> 1) sudo chown root:adm /bin/dmesg >> 2) sudo chmod 0750 /bin/dmesg >> 3) sudo setcap cap_syslog=ep /bin/dmesg >> 4) sudo sysctl -w kernel.dmesg_restrict=1 >> >> You admin user will be able to access dmesg like normal, and if you make a >> unprivileged user, they will see: >> >> $ dmesg >> -bash: /usr/bin/dmesg: Permission denied >> >> Let me know your thoughts and concerns. >> >> Note: This is NOT an attempt to remove 'adm' from the default admin user. >> Having access to 'adm' as the default user is what makes Ubuntu special and >> easy to use, and I wouldn't want to place a breaking change like that on our >> community. >> >> Thanks, >> Matthew Ruffell >> Sustaining Engineering >> >> [1] >> https://www.kernel.org/doc/html/latest/admin-guide/sysctl/kernel.html#dmesg-restrict >> > > > Some historical context: > > https://lists.ubuntu.com/archives/ubuntu-devel/2011-May/033240.html > > Marc. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel