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
debian sid --> lxde
Hello everybody. Yesterday I began to try install sid in my computer. So, I have a buster installation and i changed the source.list to sid, like that: " # deb cdrom:[Debian GNU/Linux 10.2.0 _Buster_ - Official amd64 NETINST 20191116-09:56]/ buster main #deb cdrom:[Debian GNU/Linux 10.2.0 _Buster_ - Official amd64 NETINST 20191116-09:56]/ buster main deb http://deb.debian.org/debian/ sid main deb-src http://deb.debian.org/debian/ sid main #deb http://security.debian.org/debian-security buster/updates main #deb-src http://security.debian.org/debian-security buster/updates main # buster-updates, previously known as 'volatile' #deb http://deb.debian.org/debian/ buster-updates main #deb-src http://deb.debian.org/debian/ buster-updates main # This system was installed using small removable media # (e.g. netinst, live or single CD). The matching "deb cdrom" # entries were disabled at the end of the installation process. # For information about how to configure apt package sources, # see the sources.list(5) manual. " After that I executed apt-update and apt full-upgrade, so after that show me that the "wicd" will removed, but I can't do that because if I do that I will lost the program that configure my WiFi. So How I do to resolve that? Regards, Tiago Zaniquelli
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
Bug#968523: ITP: libnsl -- Public client interface for NIS(YP) and NIS+
Package: wnpp Severity: wishlist Owner: Aurelien Jarno X-Debbugs-Cc: debian-devel@lists.debian.org, debian-gl...@lists.debian.org * Package name: libnsl Version : 1.3.0 Upstream Author : Thorsten Kukuk * URL : https://github.com/thkukuk/libnsl * License : LGPL-2.1, LGPL-2.1+, BSD-3-clause Programming Lang: C Description : Public client interface for NIS(YP) and NIS+ This package contains the libnsl library, which contains the public client interface for NIS(YP) and NIS+. This code was formerly part of glibc, but is now standalone to be able to link against TI-RPC for IPv6 support. glibc 2.32 removed support for linking against the libnsl.so.1 library, although the library is still shipped. The libnsl library, providing libnsl.so.2 (so that it is co-installable), now replaces it. This package will be maintained within the glibc team.
Bug#968510: ITP: xref-el -- Library for cross-referencing commands in Emacs
Package: wnpp Severity: wishlist Owner: Sean Whitton * Package name: xref-el Version : 1.0.2 Upstream Author : FSF * URL : https://www.example.org/ * License : GPL-3+ Programming Lang: Emacs Lisp Description : Library for cross-referencing commands in Emacs This is a newer version of xref.el than the one included with Emacs 27. I am packaging it as a dependency for the latest version of my package project-el. This is similar to seq-el and org-mode, which are also bundled with Emacs, but where we have more recent versions available as a separate package. -- Sean Whitton signature.asc Description: PGP signature
Bug#968507: O: icon-naming-utils -- script for maintaining backwards compatibility of Tango Project
Package: wnpp Severity: normal I intend to orphan the icon-naming-utils package. Last upstream release was 11 years ago. There is effectively no churn in this package. It is also a required build dependency for a bunch of icon themes: # Broken Build-Depends: extra-xdg-menus: icon-naming-utils gnome-icon-theme: icon-naming-utils (>= 0.8.7) human-icon-theme/non-free: icon-naming-utils (>= 0.8.1) mate-icon-theme: icon-naming-utils (>= 0.8.7) mate-themes: icon-naming-utils metatheme-gilouche: icon-naming-utils moblin-icon-theme: icon-naming-utils sugar-artwork: icon-naming-utils suru-icon-theme: icon-naming-utils tangerine-icon-theme/non-free: icon-naming-utils (>= 0.7.1) tango-icon-theme: icon-naming-utils (>= 0.8.90) The package description is: Tango is a project to create a new cross-desktop and cross-platform icon theme, using a standard style guide, and the new Icon Naming Specification. This package contains the perl script for maintaining backwards compatibility.
Re: Britney misses builds for architecture not listed in control
On Sun, 2020-08-16 at 15:51 +0200, Attila Szalay wrote: > I have a relatively new package (BoxFort). In the beginning, I used > the "any" architecture in the control so it was (tried to be) > compiled on all architectures. But from the build logs, I > realized that currently the package can only be compiled/used in a > very few architectures (amd64, arm64, i386) because of various > reasons. > > Also, a bit late, I learned that if I have a package with only a > static library inside, I do not need the lib package, only the -dev. > So I dropped the lib package for the next upstream version and > limited the architecture to the reliable 4 and uploaded it to the new > pool. > > But for some reason (either because the dropped lib package or post- > initial arch change) the Britney miss the "armel" and the "armhf" > architectures and not let the package arrive at testing. It's the latter. You stopped building the binary package on those architectures but the old binary packages are still in unstable. You could check this yourself on e.g. the ftp-master mirror (or by looking at the relevant packages files): $ dak ls boxfort -S boxfort| 0.0.0-git20200105-3e16c0a-2 | unstable | source boxfort| 0.0.0-git20200105-3e16c0a-6 | unstable | source boxfort| 0.0.0-git20200808-ac0507b-2 | unstable | source libboxfort | 0.0.0-git20200105-3e16c0a-2 | unstable | armel libboxfort | 0.0.0-git20200105-3e16c0a-6 | unstable | armhf libboxfort-dev | 0.0.0-git20200105-3e16c0a-2 | unstable | armel libboxfort-dev | 0.0.0-git20200105-3e16c0a-6 | unstable | armhf libboxfort-dev | 0.0.0-git20200808-ac0507b-2 | unstable | amd64, arm64, i386 > What can be done to fix this situation? You need to ask ftp-master to remove the old binaries, via an appropriately-titled ftp.debian.org bug. Regards, Adam
Britney misses builds for architecture not listed in control
Hi, I have a relatively new package (BoxFort). In the beginning, I used the "any" architecture in the control so it was (tried to be) compiled on all architectures. But from the build logs, I realized that currently the package can only be compiled/used in a very few architectures (amd64, arm64, i386) because of various reasons. Also, a bit late, I learned that if I have a package with only a static library inside, I do not need the lib package, only the -dev. So I dropped the lib package for the next upstream version and limited the architecture to the reliable 4 and uploaded it to the new pool. But for some reason (either because the dropped lib package or post-initial arch change) the Britney miss the "armel" and the "armhf" architectures and not let the package arrive at testing. What can be done to fix this situation?
Bug#968495: ITP: c-evo -- empire building game
Package: wnpp Severity: wishlist Owner: Peter Blackman X-Debbugs-CC: debian-devel@lists.debian.org * Package name : c-evo Version : 1.2.0 Upstream Author : Jiri Hajda * URL : http://www.c-evo.org/ https://app.zdechov.net/c-evo/ * License : GPL2+ Programming Lang: FPC / Lazarus Description : Empire Building Game A civilization style turn based strategy game, of the Civ2 era. C-evo has some similarities to FreeCiv, but substantial differences too. 1) City sprawl in C-evo is a losing strategy. You must build large cities to win. 2) Combat is completely deterministic, no random element. 3) Much tougher AI opponents. 4) Combat units must be designed, with chosen attack, defence & speed parameters. Cost is roughly the product of all three, so designs must specialise to keep costs reasonable. Peter signature.asc Description: OpenPGP digital signature
