Re: Proposal: Allowing access to dmesg for users in group adm
* Nicholas D. Steeves: > 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? I don't think so. sudo should be dedicated to sudo access management. I expect that system administrators would be surprised if it confers completely unrelated privileges.
Re: Proposal: Allowing access to dmesg for users in group adm
Hi, Ansgar 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
Re: Proposal: Allowing access to dmesg for users in group adm
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
Re: Proposal: Allowing access to dmesg for users in group adm
On 2020-08-17 at 07:47, Bastian Blank wrote: > Hi > > On Mon, Aug 17, 2020 at 03:50:37PM +1200, Matthew Ruffell wrote: > >> 2) Following changes to /bin/dmesg permissions in package >> 'util-linux' >> - Ownership changes to root:adm >> - Permissions changed to 0750 (-rwxr-x---) > > You mean 0754? I missed this detail of the proposal. Please ignore my previous mail. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Proposal: Allowing access to dmesg for users in group adm
Hi On Mon, Aug 17, 2020 at 03:50:37PM +1200, Matthew Ruffell wrote: > 2) Following changes to /bin/dmesg permissions in package 'util-linux' > - Ownership changes to root:adm > - Permissions changed to 0750 (-rwxr-x---) You mean 0754? > - Add cap_syslog capability to binary. Can someone please confirm that filesystem capabilities are restricted to the current user namespace? Otherwise this could allow stuff like containers to read host status. What happens if using capabilities fail? Bastian -- Captain's Log, star date 21:34.5...
Re: Proposal: Allowing access to dmesg for users in group adm
On 2020-08-17 at 07:42, Marco d'Itri wrote: > And what would be the point of setting kernel.dmesg_restrict=0 al long > as dmesg is still not world-executable? As far as I'm aware, it is: $ dlocate `which dmesg` util-linux: /bin/dmesg $ apt-cache policy util-linux util-linux: Installed: 2.36-2 Candidate: 2.36-2 Version table: *** 2.36-2 900 900 http://ftp.us.debian.org/debian testing/main amd64 Packages 100 /var/lib/dpkg/status 2.33.1-0.1 800 800 http://ftp.us.debian.org/debian stable/main amd64 Packages $ ls -lh `which dmesg` -rwxr-xr-x 1 root root 83K Aug 1 13:28 /bin/dmesg Is there some Debian context in which this isn't the case? -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Proposal: Allowing access to dmesg for users in group adm
On Aug 17, 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. Which is already the default for Debian. > 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. Looks good to me. > 3) Add a commented out '# kernel.dmesg_restrict = 0' to >/etc/sysctl.d/10-kernel-hardening.conf Debian does not have this file, so I am not sure if it should be introduced just for this. And what would be the point of setting kernel.dmesg_restrict=0 al long as dmesg is still not world-executable? -- ciao, Marco signature.asc Description: PGP signature
Re: Proposal: Allowing access to dmesg for users in group adm
On Mon, Aug 17, 2020 at 03:50:37PM +1200, Matthew Ruffell wrote: > Hello! > > I am currently working on a downstream effort to get > CONFIG_SECURITY_DMESG_RESTRICT enabled in Ubuntu, and I would like to see if > the Debian community is interested in carrying some of my proposed patches to > Ubuntu. > > Debian already has CONFIG_SECURITY_DMESG_RESTRICT enabled by default since > Stretch, but the dmesg command is restricted to superuser only. This is > inconsistent with regular logging, which is only restricted to users in group > "adm". > > For example, on a fresh Debian Buster system: > > $ head -1 /etc/os-release > PRETTY_NAME="Debian GNU/Linux 10 (buster)" > > DMESG_RESTRICT is enabled, and my user is in group adm: > > $ grep -Rin "CONFIG_SECURITY_DMESG_RESTRICT" > /boot/config-4.19.0-10-cloud-amd64 > 3130:CONFIG_SECURITY_DMESG_RESTRICT=y > $ groups > mruffell adm dip video plugdev > > Permissions for kern.log and syslog are for members of adm: > > $ ls -l /var/log/kern.log > -rw-r- 1 root adm 39414 Aug 11 21:44 /var/log/kern.log > $ ls -l /var/log/syslog > -rw-r- 1 root adm 60744 Aug 11 21:56 /var/log/syslog > > I can read /var/log/kern.log and journalctl: > > $ head -2 /var/log/kern.log > Aug 11 21:44:44 debian kernel: [0.00] Linux version > 4.19.0-10-cloud-amd64 (debian-kernel at lists.debian.org) (gcc version 8.3.0 > (Debian 8.3.0-6)) #1 SMP Debian 4.19.132-1 (2020-07-24) > Aug 11 21:44:44 debian kernel: [0.00] Command line: > BOOT_IMAGE=/boot/vmlinuz-4.19.0-10-cloud-amd64 > root=UUID=fb69ad1f-43c0-40a4-8ec0-bb07f1175c82 ro console=tty0 > console=ttyS0,115200 earlyprintk=ttyS0,115200 elevator=noop > scsi_mod.use_blk_mq=Y > > $ journalctl -t kernel | head -3 > -- Logs begin at Tue 2020-08-11 21:44:43 UTC, end at Tue 2020-08-11 22:12:30 > UTC. -- > Aug 11 21:44:43 debian kernel: Linux version 4.19.0-10-cloud-amd64 > (debian-kernel at lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 > SMP Debian 4.19.132-1 (2020-07-24) > Aug 11 21:44:43 debian kernel: Command line: > BOOT_IMAGE=/boot/vmlinuz-4.19.0-10-cloud-amd64 > root=UUID=fb69ad1f-43c0-40a4-8ec0-bb07f1175c82 ro console=tty0 > console=ttyS0,115200 earlyprintk=ttyS0,115200 elevator=noop > scsi_mod.use_blk_mq=Y > > And yet, I cannot access dmesg: > > $ dmesg > dmesg: read kernel buffer failed: Operation not permitted > $ ls -l /bin/dmesg > -rwxr-xr-x 1 root root 84288 Jan 10 2019 /bin/dmesg > > Users on Ubuntu are accustomed to running dmesg without any permissions, which > is why my downstream proposal to Ubuntu contained the following: > > 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 > > You can read my original proposal on ubuntu-devel if you are interested: > https://lists.ubuntu.com/archives/ubuntu-devel/2020-June/041063.html > > Would the Debian community also be interested in the changes to the dmesg > binary in package util-linux? > > An example debdiff of the suggested changes which implement 2) is below: > https://launchpadlibrarian.net/492806625/lp1886112_util-linux_groovy.debdiff > > This would allow any user in group adm to be able to run dmesg without > becoming superuser, and see the same information already available in > /var/log/kern.log, /var/log/syslog and journalctl. Correct. > Please let me know if you are interested, Yes I'm interested in this feature > as it enhances user experience when running dmesg, Yes, it does feel strange to prefix a readonly actio as dmesg with sudo. > and there would be less delta between Debian and Ubuntu > util-linux packages to maintain. That is a nice extra > Thanks, > Matthew Ruffell Groeten Geert Stappers DD -- Silence is hard to parse
Proposal: Allowing access to dmesg for users in group adm
Hello! I am currently working on a downstream effort to get CONFIG_SECURITY_DMESG_RESTRICT enabled in Ubuntu, and I would like to see if the Debian community is interested in carrying some of my proposed patches to Ubuntu. Debian already has CONFIG_SECURITY_DMESG_RESTRICT enabled by default since Stretch, but the dmesg command is restricted to superuser only. This is inconsistent with regular logging, which is only restricted to users in group "adm". For example, on a fresh Debian Buster system: $ head -1 /etc/os-release PRETTY_NAME="Debian GNU/Linux 10 (buster)" DMESG_RESTRICT is enabled, and my user is in group adm: $ grep -Rin "CONFIG_SECURITY_DMESG_RESTRICT" /boot/config-4.19.0-10-cloud-amd64 3130:CONFIG_SECURITY_DMESG_RESTRICT=y $ groups mruffell adm dip video plugdev Permissions for kern.log and syslog are for members of adm: $ ls -l /var/log/kern.log -rw-r- 1 root adm 39414 Aug 11 21:44 /var/log/kern.log $ ls -l /var/log/syslog -rw-r- 1 root adm 60744 Aug 11 21:56 /var/log/syslog I can read /var/log/kern.log and journalctl: $ head -2 /var/log/kern.log Aug 11 21:44:44 debian kernel: [0.00] Linux version 4.19.0-10-cloud-amd64 (debian-kernel at lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.132-1 (2020-07-24) Aug 11 21:44:44 debian kernel: [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-10-cloud-amd64 root=UUID=fb69ad1f-43c0-40a4-8ec0-bb07f1175c82 ro console=tty0 console=ttyS0,115200 earlyprintk=ttyS0,115200 elevator=noop scsi_mod.use_blk_mq=Y $ journalctl -t kernel | head -3 -- Logs begin at Tue 2020-08-11 21:44:43 UTC, end at Tue 2020-08-11 22:12:30 UTC. -- Aug 11 21:44:43 debian kernel: Linux version 4.19.0-10-cloud-amd64 (debian-kernel at lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.132-1 (2020-07-24) Aug 11 21:44:43 debian kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-10-cloud-amd64 root=UUID=fb69ad1f-43c0-40a4-8ec0-bb07f1175c82 ro console=tty0 console=ttyS0,115200 earlyprintk=ttyS0,115200 elevator=noop scsi_mod.use_blk_mq=Y And yet, I cannot access dmesg: $ dmesg dmesg: read kernel buffer failed: Operation not permitted $ ls -l /bin/dmesg -rwxr-xr-x 1 root root 84288 Jan 10 2019 /bin/dmesg Users on Ubuntu are accustomed to running dmesg without any permissions, which is why my downstream proposal to Ubuntu contained the following: 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 You can read my original proposal on ubuntu-devel if you are interested: https://lists.ubuntu.com/archives/ubuntu-devel/2020-June/041063.html Would the Debian community also be interested in the changes to the dmesg binary in package util-linux? An example debdiff of the suggested changes which implement 2) is below: https://launchpadlibrarian.net/492806625/lp1886112_util-linux_groovy.debdiff This would allow any user in group adm to be able to run dmesg without becoming superuser, and see the same information already available in /var/log/kern.log, /var/log/syslog and journalctl. Please let me know if you are interested, as it enhances user experience when running dmesg, and there would be less delta between Debian and Ubuntu util-linux packages to maintain. Thanks, Matthew Ruffell
