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
