Sunday 30 August 2020

Re: Proposal: Enabling DMESG_RESTRICT for Groovy Onward

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

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel