Package: lintian Version: 2.5.72 Severity: normal Tags: patch It would be nice to explain to maintainers how to avoid using chmod -R.
The attached patch makes the description of the problem and some possible steps to resolve it better. it also points to another similar bug in ntp. --dkg -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'oldstable'), (200, 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lintian depends on: ii binutils 2.29.1-13 ii bzip2 1.0.6-8.1 ii diffstat 1.61-1+b1 ii dpkg 1.19.0.5 ii file 1:5.32-1 ii gettext 0.19.8.1-4 ii intltool-debian 0.35.0+20060710.4 ii libapt-pkg-perl 0.1.33 ii libarchive-zip-perl 1.60-1 ii libclass-accessor-perl 0.51-1 ii libclone-perl 0.39-1 ii libdpkg-perl 1.19.0.5 ii libemail-valid-perl 1.202-1 ii libfile-basedir-perl 0.07-1 ii libipc-run-perl 0.96-1 ii liblist-moreutils-perl 0.416-1+b3 ii libparse-debianchangelog-perl 1.2.0-12 ii libperl5.24 [libdigest-sha-perl] 5.24.1-7 ii libperl5.26 [libdigest-sha-perl] 5.26.1-4 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3000-2 ii liburi-perl 1.73-1 ii libxml-simple-perl 2.24-1 ii libyaml-libyaml-perl 0.69+repack-1 ii man-db 2.7.6.1-4 ii patchutils 0.3.4-2 ii perl 5.26.1-4 ii t1utils 1.41-2 ii xz-utils 5.2.2-1.3 Versions of packages lintian recommends: pn libperlio-gzip-perl <none> Versions of packages lintian suggests: pn binutils-multiarch <none> ii dpkg-dev 1.19.0.5 ii libhtml-parser-perl 3.72-3+b2 ii libtext-template-perl 1.47-1 -- no debconf information
>From 86eed052809dac1bb66fd9511d5884b54d705948 Mon Sep 17 00:00:00 2001 From: Daniel Kahn Gillmor <d...@fifthhorseman.net> Date: Sat, 3 Feb 2018 15:15:50 -0500 Subject: [PATCH] Add more suggestions for how to avoid recursive chown. Many recursive chown vulnerabilities are just overkill, which can be fixed by not doing that any more. Some have legitimate reasons for doing the recursive chown, and are tougher to solve. Offer developers some suggestions about how to avoid the problematic behavior in the lintian tag description. --- checks/scripts.desc | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/checks/scripts.desc b/checks/scripts.desc index 176b8a198..1bf19fc91 100644 --- a/checks/scripts.desc +++ b/checks/scripts.desc @@ -819,4 +819,22 @@ Certainty: certain Info: The maintainer script appears to call <tt>chmod</tt> or <tt>chown</tt> with the recursive <tt>-R</tt> argument. This is vulnerable to hardlink attacks on kernels that do not have <tt>fs.protected_hardlinks=1</tt> -Ref: #889060 + . + The risk lies in the act of changing permissions or ownership within + a directory that may already be owned by an otherwise non-privileged + user. On mainline kernels, such a user can link to files that they + do not own, like <tt>/etc/shadow</tt> or files within + <tt>/var/lib/dpkg/</tt>. A promiscuous chown or chmod could convert + the ownership or permissions of these sensitive files so that they + are manipulable by the non-privileged user. + . + Some ways to avoid the problem: + . + - If your package uses a static uid, do the chown at package build + time instead of installation time. + - Use targeted, non-recursive chown instead, ensuring that you do + not change ownership of files that are in user-controlled + directories. + - Use <tt>runuser</tt> to do initialization work as the user you + would chown to. +Ref: #889060, #889488 -- 2.15.1
