https://gitlab.com/cki-project/kernel-ark/-/commit/ed5ba266c61e01a52359b5793...
Why wasn't this a Fedora change proposal?
Also the justification given for such a major change is very thin. I'm sure product security can give us some more details of precisely what exploits will be mitigated, in the change proposal.
Rich.
Once upon a time, Richard W.M. Jones rjones@redhat.com said:
https://gitlab.com/cki-project/kernel-ark/-/commit/ed5ba266c61e01a52359b5793...
Why wasn't this a Fedora change proposal?
Also the justification given for such a major change is very thin. I'm sure product security can give us some more details of precisely what exploits will be mitigated, in the change proposal.
It's not just Rawhide, it was changed in F39 mid-stream with the 6.7 kernel (and no notice/announcement).
On Tue, Feb 27, 2024 at 2:16 PM Richard W.M. Jones rjones@redhat.com wrote:
https://gitlab.com/cki-project/kernel-ark/-/commit/ed5ba266c61e01a52359b5793...
Why wasn't this a Fedora change proposal?
Also the justification given for such a major change is very thin. I'm sure product security can give us some more details of precisely what exploits will be mitigated, in the change proposal.
In practice, this isn't that much of a lockdown for most fedora users. We give the default user on a system wheel access which means both 'sudo dmesg' and 'journalctl -k' work as is. While giving existing CVE numbers that are easier/possible to exploit doesn't much matter because they should be fixed already, It gets rid of a number of exploits where you need information that is only available via oops etc.
Justin
Rich.
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
W dniu 27.02.2024 o 22:27, Justin Forbes pisze:
In practice, this isn't that much of a lockdown for most fedora users. We give the default user on a system wheel access which means both 'sudo dmesg' and 'journalctl -k' work as is.
You wish...
$ id uid=1003(marcin) gid=1006(marcin) groups=1006(marcin),10(wheel),11(cdrom),18(dialout),39(video),63(audio),100(users),135(mock),948(render),960(libvirt),986(wireshark),1003(docker) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 $ dmesg dmesg: read kernel buffer failed: Operation not permitted $ uname -a Linux puchatek.local 6.8.0-0.rc5.41.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Feb 19 14:19:27 UTC 2024 x86_64 GNU/Linux
On 28/02/2024 10:05, Marcin Juszkiewicz wrote:
W dniu 27.02.2024 o 22:27, Justin Forbes pisze:
In practice, this isn't that much of a lockdown for most fedora users. We give the default user on a system wheel access which means both 'sudo dmesg' and 'journalctl -k' work as is.
You wish...
$ id uid=1003(marcin) gid=1006(marcin) groups=1006(marcin),10(wheel),11(cdrom),18(dialout),39(video),63(audio),100(users),135(mock),948(render),960(libvirt),986(wireshark),1003(docker) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 $ dmesg dmesg: read kernel buffer failed: Operation not permitted $ uname -a Linux puchatek.local 6.8.0-0.rc5.41.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Feb 19 14:19:27 UTC 2024 x86_64 GNU/Linux
Which proves what? You did "dmesg" not "sudo dmesg" or "journalctl -k".
Tom
On Tue, Feb 27, 2024 at 08:15:49PM +0000, Richard W.M. Jones wrote:
https://gitlab.com/cki-project/kernel-ark/-/commit/ed5ba266c61e01a52359b5793...
Why wasn't this a Fedora change proposal?
Also the justification given for such a major change is very thin. I'm sure product security can give us some more details of precisely what exploits will be mitigated, in the change proposal.
FWIW, Googling for 'CONFIG_SECURITY_DMESG_RESTRICT' finds several posts illustrating techniques for exploiting historical CVEs that would be made harder were CONFIG_SECURITY_DMESG_RESTRICT set, preventing dmesg from undermining KASLR by leaking kernel addresses to unprivileged processes.
With regards, Daniel
On Tue, Feb 27, 2024 at 08:15:49PM +0000, Richard W.M. Jones wrote:
https://gitlab.com/cki-project/kernel-ark/-/commit/ed5ba266c61e01a52359b5793...
Why wasn't this a Fedora change proposal?
Also the justification given for such a major change is very thin. I'm sure product security can give us some more details of precisely what exploits will be mitigated, in the change proposal.
You can restore the original behavior by using:
# sysctl kernel.dmesg_restrict=0
However, be aware of the security consequences ;-)
On Wed, Feb 28, 2024 at 11:24:41AM +0100, Karel Zak wrote:
On Tue, Feb 27, 2024 at 08:15:49PM +0000, Richard W.M. Jones wrote:
https://gitlab.com/cki-project/kernel-ark/-/commit/ed5ba266c61e01a52359b5793...
Why wasn't this a Fedora change proposal?
Also the justification given for such a major change is very thin. I'm sure product security can give us some more details of precisely what exploits will be mitigated, in the change proposal.
You can restore the original behavior by using:
# sysctl kernel.dmesg_restrict=0However, be aware of the security consequences ;-)
Right ... which are what exactly?
I don't have untrusted local users, and if I wanted to host untrusted local users I'd need to do a lot of extra lock down, so perhaps the default here can be kernel.dmesg_restrict=0 with kernel.dmesg_restrict=1 being used on locked down systems.
Rich.
On Wed, Feb 28, 2024 at 10:30:10AM +0000, Richard W.M. Jones wrote:
On Wed, Feb 28, 2024 at 11:24:41AM +0100, Karel Zak wrote:
On Tue, Feb 27, 2024 at 08:15:49PM +0000, Richard W.M. Jones wrote:
https://gitlab.com/cki-project/kernel-ark/-/commit/ed5ba266c61e01a52359b5793...
Why wasn't this a Fedora change proposal?
Also the justification given for such a major change is very thin. I'm sure product security can give us some more details of precisely what exploits will be mitigated, in the change proposal.
You can restore the original behavior by using:
# sysctl kernel.dmesg_restrict=0However, be aware of the security consequences ;-)
Right ... which are what exactly?
I don't have untrusted local users, and if I wanted to host untrusted local users I'd need to do a lot of extra lock down, so perhaps the default here can be kernel.dmesg_restrict=0 with kernel.dmesg_restrict=1 being used on locked down systems.
The protection against information leakage applies to system services as much as to interactive local users, so it is still valid hardening to do even on single user machines IMHO.
With regards, Daniel
On 28 Feb 2024, at 10:24, Karel Zak kzak@redhat.com wrote:
You can restore the original behavior by using:
# sysctl kernel.dmesg_restrict=0
However, be aware of the security consequences ;-)
Given I can get the same information from journalctl -k what is the improvement?
Barry
On Wed, 28 Feb 2024 at 13:38, Barry Scott barry@barrys-emacs.org wrote:
On 28 Feb 2024, at 10:24, Karel Zak kzak@redhat.com wrote:
You can restore the original behavior by using:
# sysctl kernel.dmesg_restrict=0
However, be aware of the security consequences ;-)
Given I can get the same information from journalctl -k what is the improvement?
I believe you need to be in the wheel group to get that info from journalctl
On Wed, Feb 28, 2024, at 6:45 AM, Peter Robinson wrote:
On Wed, 28 Feb 2024 at 13:38, Barry Scott barry@barrys-emacs.org wrote:
On 28 Feb 2024, at 10:24, Karel Zak kzak@redhat.com wrote:
You can restore the original behavior by using:
# sysctl kernel.dmesg_restrict=0
However, be aware of the security consequences ;-)
Given I can get the same information from journalctl -k what is the improvement?
I believe you need to be in the wheel group to get that info from journalctl
I'm in the wheel group as is everyone else by default installing Fedora. A vast majority of Fedora users have this peculiar UX where `journalctl -k` not not require `sudo` but `dmesg` does require it. I think that's annoying and weird.
On Mon, Mar 04, 2024 at 11:37:49PM -0700, Chris Murphy wrote:
On Wed, Feb 28, 2024, at 6:45 AM, Peter Robinson wrote:
On Wed, 28 Feb 2024 at 13:38, Barry Scott barry@barrys-emacs.org wrote:
On 28 Feb 2024, at 10:24, Karel Zak kzak@redhat.com wrote:
You can restore the original behavior by using:
# sysctl kernel.dmesg_restrict=0
However, be aware of the security consequences ;-)
Given I can get the same information from journalctl -k what is the improvement?
I believe you need to be in the wheel group to get that info from journalctl
I'm in the wheel group as is everyone else by default installing Fedora. A vast majority of Fedora users have this peculiar UX where `journalctl -k` not not require `sudo` but `dmesg` does require it. I think that's annoying and weird.
That is true. But please note that there's a huge list of processes that are not in the wheel group: e.g. any random service on the system that is running unprivileged. Previously, it would have access to dmesg, possibly making it easier to escalate some vulnerability to full root access. With this change, dmesg becomes unavailable so extracting information about the running kernel is harder.
Zbyszek
-
Barry Scott -
Chris Adams -
Chris Murphy -
Daniel P. Berrangé -
Justin Forbes -
Karel Zak -
Marcin Juszkiewicz -
Peter Robinson -
Richard W.M. Jones -
Tom Hughes -
Zbigniew Jędrzejewski-Szmek