Proposal: Enabling DMESG_RESTRICT for Groovy Onward
Matthew Ruffell
matthew.ruffell at canonical.com
Mon Aug 31 00:01:01 UTC 2020
Hi Chris, Steve,
>> I'm sure you have seen Ansgar's reply here:
>> https://lists.debian.org/debian-devel/2020/08/msg00121.html
>
>> > That grants additional rights to the `adm` group that it did not have
>> > before, for example to clear the dmesg buffer:
>> >
>> > $ dmesg --clear
>> >
>> > works after adding `cap_syslog` to the dmesg binary whereas it did not
>> > work before.
>
>> This makes me want to -NOT- apply these changes in Debian's
>> util-linux.
Yes, I did see Ansgar's reply, and at that moment I realised that opening dmesg
to members of adm would be a bad idea. Clearing the dmesg buffer should always
be a restricted action.
Its a pity that cap_syslog doesn't have a read-only sister capability. Maybe
something for the future.
>
>> Re-enabling dmesg for the %adm group does not seem to add value for
>> Debian now, and granting the --clear (and other) permissions seems
>> to be too much.
>
> I agree, and on that basis I also do not believe we should include this
> change to util-linux in Ubuntu.
>
Roger that, I understand entirely. I will mark the Launchpad bug for util-linux
as Won't Fix.
At least now we have a concrete paper trail on why dmesg hasn't been opened up
to members of adm in the past, for future searchers.
The 5.8.0-16-generic kernel in Ubuntu Groovy has landed in the -release pocket
now, with CONFIG_SECURITY_DMESG_RESTRICT enabled, so Ubuntu will now receive
the additional hardening dmesg_restrict provides. I hope that executing dmesg
as superuser isn't too inconvenient for Ubuntu users. Time will tell.
Chris, thanks for at least entertaining the idea of the changes to util-linux,
and for following the mailing list chatter.
Thanks,
Matthew
More information about the ubuntu-devel
mailing list