Hi, Ansgar <ans...@debian.org> writes:
> On Mon, 2020-08-17 at 15:50 +1200, Matthew Ruffell wrote: >> I propose that we restrict access to dmesg to users in group 'adm' like so: >> >> 1) CONFIG_SECURITY_DMESG_RESTRICT=y in the kernel. >> 2) Following changes to /bin/dmesg permissions in package 'util-linux' >> - Ownership changes to root:adm >> - Permissions changed to 0750 (-rwxr-x---) >> - Add cap_syslog capability to binary. >> 3) Add a commented out '# kernel.dmesg_restrict = 0' to >> /etc/sysctl.d/10-kernel-hardening.conf > > 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. > > Ansgar Wow, this surprised me. Thank you for this insight :-) Given that our default sudoers (and afaik Ubuntu's) provides the following rule %sudo ALL=(ALL:ALL) ALL would it be reasonable to modify this proposal to use the "sudo" rather than "adm" group, given that we don't yet have a default mechanism to enforce a "if groups = (sudo AND adm)" mechanism? Or is it possible to get rich access controls by a fallback sequence like "if apparmor, else selinux, else yama, else fs ACLs, else default-restrictive-policy"? Apologies for being ignorant about the state of the art! Regards, Nicholas
signature.asc
Description: PGP signature
