dmesg: read kernel buffer failed: Operation not permitted

Asked by tomdean on 2021-05-04

After a dist-upgrade,

> dmesg
dmesg: read kernel buffer failed: Operation not permitted

But,
> sudo dmesg|wc
   1003 8845 71410

works.
/etc/sysctl.d/10-kernel-hardening.conf
# These settings are specific to hardening the kernel itself from attack
# from userspace, rather than protecting userspace from other malicious
# userspace things.
#
#
# When an attacker is trying to exploit the local kernel, it is often
# helpful to be able to examine where in memory the kernel, modules,
# and data structures live. As such, kernel addresses should be treated
# as sensitive information.
#
# Many files and interfaces contain these addresses (e.g. /proc/kallsyms,
# /proc/modules, etc), and this setting can censor the addresses. A value
# of "0" allows all users to see the kernel addresses. A value of "1"
# limits visibility to the root user, and "2" blocks even the root user.
kernel.kptr_restrict = 1

????

Question information

Language:
English Edit question
Status:
Solved
For:
Ubuntu Edit question
Assignee:
No assignee Edit question
Solved by:
Manfred Hampl
Solved:
Last query:
Last reply:
Best Manfred Hampl (m-hampl) said : #1

According to https://unix.stackexchange.com/a/390187 the relevant setting for re-enabling is kernel.dmesg_restrict=0

I do not know when this access restriction was introduced in Ubuntu, but I first noticed it in Ubuntu 20.10

tomdean (tomdean) said : #2

On 5/4/21 3:15 AM, Manfred Hampl wrote:
> Your question #696903 on Ubuntu changed:
> https://answers.launchpad.net/ubuntu/+question/696903
>
> Status: Open => Answered
>
> Manfred Hampl proposed the following answer:
> According to https://unix.stackexchange.com/a/390187 the relevant
> setting for re-enabling is kernel.dmesg_restrict=0
>
> I do not know when this access restriction was introduced in Ubuntu, but
> I first noticed it in Ubuntu 20.10
>

I just updated a system from 18.04 to 20.04 via do-release-upgrade.
It installed the 5.11.0-7614-generic kernel.

I fixed it by changing /etc/sysctl.conf

Like I said, big brother...

tomdean (tomdean) said : #3

Nothing to solve, but, close it anyway.

It was just a rant...

Manfred Hampl (m-hampl) said : #4

"Like I said, big brother..."

Why? In my opinion just the opposite: A non-admin user cannot look in the log files for traces of actions executed by somebody else.