Enable CONFIG_SECURITY_DMESG_RESTRICT

[Leann Ogasawara]

There is a request to enable the following for linux-aws.

config SECURITY_DMESG_RESTRICT
        bool "Restrict unprivileged access to the kernel syslog"
        default n
        help
          This enforces restrictions on unprivileged users reading the kernel
          syslog via dmesg(8).

          If this option is not selected, no restrictions will be enforced
          unless the dmesg_restrict sysctl is explicitly set to (1).

          If you are unsure how to answer this question, answer N.

[Joseph Salisbury (jsalisbury)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1696558

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Scott Emmons (lscotte)]

This bug is not to track a problem, it's to change a default kernel option to a more secure setting already in use by other distributions, such as upstream Debian.

[Po-Hsu Lin (cypressyew)]

https://lists.ubuntu.com/archives/kernel-team/2019-August/103163.html

[Tyler Hicks (tyhicks)]

I don't think that we should make this change. I explained my reasoning in this email:

  https://lists.ubuntu.com/archives/kernel-team/2019-September/103615.html

For posterity, I'm copying the content below.

=================================
While enabling kernel hardening features is something that I'd typically
advocate for, I'm not sure that this particular one is still worth the
pain that we'd inflict on our users by enabling it.

This is a kernel config option that we'd really want to globally enable
or disable across all of our kernels, rather than doing something unique
in linux-aws, because it is a very user-visible feature.

The primary motivation for enabling this is to prevent unprivileged
users, who may be trying to attack the kernel, from learning about
kernel addresses that may aide them in an attack. However, I think that
the need for this sort of protection has been reduced greatly since 4.15
with the following commit:

 https://git.kernel.org/linus/ad67b74d2469d9b82aaa572d76474c95bc484d57

There could be an argument for enabling CONFIG_SECURITY_DMESG_RESTRICT
in Xenial since its base (4.4) kernel doesn't have commit
ad67b74d2469d9b82aaa572d76474c95bc484d57 but I worry that it is too
disruptive of a change to introduce 3 years into an LTS release. It
certainly isn't appropriate to introduce the change in Trusty ESM at
this point.

I think we can close out bug #1696558 now that we have global %p
hashing.
=================================

[Po-Hsu Lin (cypressyew)]

Mark Xenial as Won't fix like others.