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