Bug#983314: linux-base: perf fails to report that linux-perf-5.10 is not installed
On Fri, 2021-02-26 at 06:47 +0100, Salvatore Bonaccorso wrote:
> Control: tags -1 + confirmed
>
> Hi Bart,
>
> On Mon, Feb 22, 2021 at 11:57:56AM +0100, Bart Martens wrote:
> > Package: linux-base
> > Version: 4.6
> > Severity: minor
> > File: /usr/bin/perf
> >
> > Observed behavior:
> >
> > $ perf
> > /usr/bin/perf: line 13: exec: perf_5.10: not found
> >
> > Expected behavior:
> >
> > $ perf
> > /usr/bin/perf: line 14: exec: perf_5.10: not found
> > E: linux-perf-5.10 is not installed.
FYI Debian Buster backports AMD64 provides 'Expected behavor' in a debian
packaging for 5.10.15-2 reiser4 build hack running in an AMD Epyc/Ryzen cloud
instance:
https://metztli.it/buster/perf.png
>
> That's intersting, confirmed. The script is the same since the buster
> release without changes, but it looks it behaves differently in a buster
> vs. unstable/bullseye environment when the replacement ${version%%-*}
> is involved after the version setting:
>
> , [ perf-minimal ]
> > #!/bin/bash
> >
> > version="$(uname -r)"
> > version="${version%%-*}"
> > shopt -s execfail
> > exec "perf_$version" "$@"
> > echo >&2 "E: not installed."
> > exit 1
> `
>
> In an buster environment:
>
> ++ uname -r
> + version=4.19.0-14-amd64
> + version=4.19.0
> + shopt -s execfail
> + exec perf_4.19.0
> ./perf-minimal: line 6: exec: perf_4.19.0: not found
> + echo 'E: not installed.'
> E: not installed.
> + exit 1
>
> In an unstable environment:
>
> bash -x ./perf-minimal
> ++ uname -r
> + version=4.19.0-14-amd64
> + version=4.19.0
> + shopt -s execfail
> + exec perf_4.19.0
> ./perf-minimal: line 6: exec: perf_4.19.0: not found
>
> Regards,
> Salvatore
>
Best Professional Regards.
--
--
Jose R R
http://metztli.it
---
Download Metztli Reiser4: Debian Buster w/ Linux 5.9.16 AMD64
---
feats ZSTD compression https://sf.net/projects/metztli-reiser4/
---
or SFRN 5.1.3, Metztli Reiser5 https://sf.net/projects/debian-reiser4/
---
Official current Reiser4 resources: https://reiser4.wiki.kernel.org/
Processed: Re: Bug#983314: linux-base: perf fails to report that linux-perf-5.10 is not installed
Processing control commands: > tags -1 + confirmed Bug #983314 [linux-base] linux-base: perf fails to report that linux-perf-5.10 is not installed Added tag(s) confirmed. -- 983314: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983314 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#983314: linux-base: perf fails to report that linux-perf-5.10 is not installed
Control: tags -1 + confirmed
Hi Bart,
On Mon, Feb 22, 2021 at 11:57:56AM +0100, Bart Martens wrote:
> Package: linux-base
> Version: 4.6
> Severity: minor
> File: /usr/bin/perf
>
> Observed behavior:
>
> $ perf
> /usr/bin/perf: line 13: exec: perf_5.10: not found
>
> Expected behavior:
>
> $ perf
> /usr/bin/perf: line 14: exec: perf_5.10: not found
> E: linux-perf-5.10 is not installed.
That's intersting, confirmed. The script is the same since the buster
release without changes, but it looks it behaves differently in a buster
vs. unstable/bullseye environment when the replacement ${version%%-*}
is involved after the version setting:
, [ perf-minimal ]
| #!/bin/bash
|
| version="$(uname -r)"
| version="${version%%-*}"
| shopt -s execfail
| exec "perf_$version" "$@"
| echo >&2 "E: not installed."
| exit 1
`
In an buster environment:
++ uname -r
+ version=4.19.0-14-amd64
+ version=4.19.0
+ shopt -s execfail
+ exec perf_4.19.0
./perf-minimal: line 6: exec: perf_4.19.0: not found
+ echo 'E: not installed.'
E: not installed.
+ exit 1
In an unstable environment:
bash -x ./perf-minimal
++ uname -r
+ version=4.19.0-14-amd64
+ version=4.19.0
+ shopt -s execfail
+ exec perf_4.19.0
./perf-minimal: line 6: exec: perf_4.19.0: not found
Regards,
Salvatore
[bts-link] source package src:linux
# # bts-link upstream status pull for source package src:linux # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # https://bts-link-team.pages.debian.net/bts-link/ # user debian-bts-l...@lists.debian.org # remote status report for #983047 (http://bugs.debian.org/983047) # Bug title: linux-image-5.10.0-3-amd64: Virtualbox Shared Folder vboxsf in 5.10 is racy / unusable with git clone # * http://bugzilla.kernel.org/show_bug.cgi?id=211171 # * remote status changed: (?) -> NEW usertags 983047 + status-NEW thanks
Processed: your mail
Processing commands for cont...@bugs.debian.org: > tags 983495 pending Bug #983495 [src:linux] linux-image-amd64: Please enable ee1004 module Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 983495: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983495 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: bug 983372 is forwarded to https://lore.kernel.org/stable/fe6040b5-72a0-9882-439e-ea7fc0b39...@redhat.com/ ...
Processing commands for cont...@bugs.debian.org: > forwarded 983372 > https://lore.kernel.org/stable/fe6040b5-72a0-9882-439e-ea7fc0b39...@redhat.com/ Bug #983372 [src:linux] linux-image-5.10.0-3-amd64: Graphic glitches / distortions when using Desktop (Plasma / KDE) Set Bug forwarded-to-address to 'https://lore.kernel.org/stable/fe6040b5-72a0-9882-439e-ea7fc0b39...@redhat.com/'. > tags 983372 + upstream Bug #983372 [src:linux] linux-image-5.10.0-3-amd64: Graphic glitches / distortions when using Desktop (Plasma / KDE) Added tag(s) upstream. > thanks Stopping processing here. Please contact me if you need assistance. -- 983372: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983372 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: found 983508 in 1:1.3.4-4
Processing commands for cont...@bugs.debian.org: > found 983508 1:1.3.4-4 Bug #983508 [nfs-common] nfs-common: Bullseys/Kernel 5.10 SAMBA AD/DC NFSv4 Kerberos Problem with rpc.gssd Marked as found in versions nfs-utils/1:1.3.4-4. > thanks Stopping processing here. Please contact me if you need assistance. -- 983508: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983508 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#983372: Correction of Bug-Report
I unfortunately pasted the wrong link to the redhat forum for further description of the bug. The correct one: https://bugzilla.redhat.com/show_bug.cgi?id=1925346 Kind regards, user2304 -- mail: user2...@web.de
Re: please consider disabling obsolete crypto in 5.10 and later
On Thu, 25 Feb 2021 at 11:35, Salvatore Bonaccorso wrote: > > Hi Ard, > > On Mon, Feb 01, 2021 at 10:21:27PM +0100, Salvatore Bonaccorso wrote: > > Hi Ard, > > > > On Sat, Jan 30, 2021 at 04:41:16PM +0100, Ard Biesheuvel wrote: > > > L.S., > > > > > > This is a request to consider disabling obsolete crypto in 5.10 and > > > later Debian builds of the Linux kernel on any architecture. > > > > > > We are all familiar with the rigid rules when it comes to not breaking > > > userspace by making changes to the kernel, but this rule only takes > > > effect when anybody notices, and so I am proposing disabling some code > > > downstream before removing it entirely. > > > > > > 5.10 introduces a new Kconfig symbol > > > > > > CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE > > > > > > which is enabled by default, but depends on support for the AF_ALG > > > socket API being enabled. In turn, block ciphers that are obsolete and > > > unlikely to be used anywhere have been made to depend on this new > > > symbol. > > > > > > This means that these obsolete block ciphers will disappear entirely > > > when the AF_ALG socket API is omitted, but we can get rid of these > > > block ciphers explicitly too, by not setting the new symbol. I.e., > > > adding > > > > > > # CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set > > > > > > to the kernel configs. Note that Fedora have already done so in release > > > 33 [0] > > > > > > The block ciphers in question are RC4, Khazad, SEED, and > > > TEA/XTEA/XETA, none of which are used by the kernel itself, or known > > > to be used via the socket API (although a change was applied to > > > iwd/libell recently to get rid of an occurrence of RC4 - this change > > > has already been pulled into bullseye afaik) > > > > > > Note that this is not a statement on whether these algorithms are > > > secure or not -there is simply no point in carrying and shipping code > > > that nobody uses or audits, but which can be autoloaded and exercised > > > via an unprivileged interface. > > > > FTR (posteriori), we tried that in > > https://salsa.debian.org/kernel-team/linux/-/commit/633e1992f7d915c22b2a2adea87981e7503bb737 > > (and is in the 5.10.12-1 upload to unstable). > > There were two reports which might be in the end related to that > change: > > https://bugs.debian.org/979764 > https://bugs.debian.org/983508 > > We have long that nfs-utils need to be updated, but the version was so > outdated, that progress on updating to a newer version stalled, and > could not be done in time for bulleye. Once bullseye is released I > guess this really needs to be prioritzed in some way. > > Ard, have you any insight in the above, so, should we revert the above > change for bullseye again? > Hello Salvatore, I think the issue is the patch below. Having something that requires RC4 and MD5 for security is an absolute joke in 2021, so I won't recommend you reverting it. Instead, you should really fix nfs-utils with priority. -- Ard. commit e33d2a7b3041d7f8cd1f0a2a4ca42a5bc112b14e Author: Ard Biesheuvel Date: Mon Aug 31 18:16:45 2020 +0300 SUNRPC: remove RC4-HMAC-MD5 support from KerberosV The RC4-HMAC-MD5 KerberosV algorithm is based on RFC 4757 [0], which was specifically issued for interoperability with Windows 2000, but was never intended to receive the same level of support. The RFC says The IETF Kerberos community supports publishing this specification as an informational document in order to describe this widely implemented technology. However, while these encryption types provide the operations necessary to implement the base Kerberos specification [RFC4120], they do not provide all the required operations in the Kerberos cryptography framework [RFC3961]. As a result, it is not generally possible to implement potential extensions to Kerberos using these encryption types. The Kerberos encryption type negotiation mechanism [RFC4537] provides one approach for using such extensions even when a Kerberos infrastructure uses long-term RC4 keys. Because this specification does not implement operations required by RFC 3961 and because of security concerns with the use of RC4 and MD4 discussed in Section 8, this specification is not appropriate for publication on the standards track. The RC4-HMAC encryption types are used to ease upgrade of existing Windows NT environments, provide strong cryptography (128-bit key lengths), and provide exportable (meet United States government export restriction requirements) encryption. This document describes the implementation of those encryption types. Furthermore, this RFC was re-classified as 'historic' by RFC 8429 [1] in 2018, stating that 'none of the encryption types it specifies should be used' Note that other outdated algorithms are left in place (some of which are guarded by
Re: please consider disabling obsolete crypto in 5.10 and later
Hi Ard, On Mon, Feb 01, 2021 at 10:21:27PM +0100, Salvatore Bonaccorso wrote: > Hi Ard, > > On Sat, Jan 30, 2021 at 04:41:16PM +0100, Ard Biesheuvel wrote: > > L.S., > > > > This is a request to consider disabling obsolete crypto in 5.10 and > > later Debian builds of the Linux kernel on any architecture. > > > > We are all familiar with the rigid rules when it comes to not breaking > > userspace by making changes to the kernel, but this rule only takes > > effect when anybody notices, and so I am proposing disabling some code > > downstream before removing it entirely. > > > > 5.10 introduces a new Kconfig symbol > > > > CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE > > > > which is enabled by default, but depends on support for the AF_ALG > > socket API being enabled. In turn, block ciphers that are obsolete and > > unlikely to be used anywhere have been made to depend on this new > > symbol. > > > > This means that these obsolete block ciphers will disappear entirely > > when the AF_ALG socket API is omitted, but we can get rid of these > > block ciphers explicitly too, by not setting the new symbol. I.e., > > adding > > > > # CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set > > > > to the kernel configs. Note that Fedora have already done so in release 33 > > [0] > > > > The block ciphers in question are RC4, Khazad, SEED, and > > TEA/XTEA/XETA, none of which are used by the kernel itself, or known > > to be used via the socket API (although a change was applied to > > iwd/libell recently to get rid of an occurrence of RC4 - this change > > has already been pulled into bullseye afaik) > > > > Note that this is not a statement on whether these algorithms are > > secure or not -there is simply no point in carrying and shipping code > > that nobody uses or audits, but which can be autoloaded and exercised > > via an unprivileged interface. > > FTR (posteriori), we tried that in > https://salsa.debian.org/kernel-team/linux/-/commit/633e1992f7d915c22b2a2adea87981e7503bb737 > (and is in the 5.10.12-1 upload to unstable). There were two reports which might be in the end related to that change: https://bugs.debian.org/979764 https://bugs.debian.org/983508 We have long that nfs-utils need to be updated, but the version was so outdated, that progress on updating to a newer version stalled, and could not be done in time for bulleye. Once bullseye is released I guess this really needs to be prioritzed in some way. Ard, have you any insight in the above, so, should we revert the above change for bullseye again? Regards, Salvatore
Bug#983508: nfs-common: Bullseys/Kernel 5.10 SAMBA AD/DC NFSv4 Kerberos Problem with rpc.gssd
Package: nfs-common Version: 1:1.3.4-2.5+deb10u1 Severity: important Tags: upstream Dear Maintainers There is a long standing bug (or wrong documentation) in rpc.gssd Probably debian uses an outdated version (new upstream version). I consider this bug as severe because it breaks backward compa- tibility since debian bullseye. It might affect most SAMBA AD/DC setups that were working with buster and fail with bulseye. PROBLEM The point is the nfs/... SPN (service principle name) that was historically used to fill the kerberos machine credential cache. The documentation explicitly states that rpc.gssd first tries the (windows) machine account $/... then a SPN (or UPN?) root/... then some others and FINALLY the nfs/... SPN. But this is wrong, only nfs/... is recognized. This creates a problem with SAMBA AD/DCs setups. Samba uses heimdal kerberos. A difference between heimdal and MIT are the SPNs. So in SAMBA you have to add a UPN (like the before mentioned root/...) and to attach the nfs/... SPN to the UPN. This is how it looks: samba-tool user create --random-password --gid-number=100 \ --gecos="nfs user" --unix-home=/tmp --login-shell=/usr/sbin/nologin \ root/myhost.centauri.home samba-tool user setexpiry --noexpiry root/myhost.centauri.home samba-tool spn add nfs/myhost.centauri.home root/myhost.centauri.home The exported keytab works fine (until kernel 5.9) and allows NFS4 with kerberos security: samba-tool domain exportkeytab xxx.keytab --principal MYHOST$ samba-tool domain exportkeytab xxx.keytab --principal root/myhost.centauri.home samba-tool domain exportkeytab xxx.keytab --principal nfs/myhost.centauri.home But as nfs/... SPN seems to be historic SAMBA only exports weak encryption keys for nfs/... whereas the machine account and the root/... UPN have strong encryption: klist -e -k /etc/krb5.keytab.old Keytab name: FILE:/etc/krb5.keytab.old KVNO Principal -- 1 alpha1$@CENTAURI.HOME (aes256-cts-hmac-sha1-96) 1 alpha1$@CENTAURI.HOME (aes128-cts-hmac-sha1-96) 1 alpha1$@CENTAURI.HOME (arcfour-hmac) 1 alpha1$@CENTAURI.HOME (des-cbc-md5) 1 alpha1$@CENTAURI.HOME (des-cbc-crc) 2 root/alpha1.centauri.h...@centauri.home (aes256-cts-hmac-sha1-96) 2 root/alpha1.centauri.h...@centauri.home (aes128-cts-hmac-sha1-96) 2 root/alpha1.centauri.h...@centauri.home (arcfour-hmac) 2 root/alpha1.centauri.h...@centauri.home (des-cbc-md5) 2 root/alpha1.centauri.h...@centauri.home (des-cbc-crc) 2 nfs/alpha1.centauri.h...@centauri.home (arcfour-hmac) 2 nfs/alpha1.centauri.h...@centauri.home (des-cbc-md5) 2 nfs/alpha1.centauri.h...@centauri.home (des-cbc-crc) SOLUTION This was OK until kernel 5.9 only. Since 5.10 somebody disabled weak encrytion in the kernel part of GSSAPI. Now debian's old rpc.gssd fails. Probably creating a security problem as NFS mount now tries NFS 3 (without kerberos). The SAMBA documentation explains the SAMBA behaviour here: https://wiki.samba.org/index.php/Generating_Keytabs The solution is to explicitly set the supported encryption for the root/... UPN: net ads enctypes set root/myhost.centauri.home 31 A newly created keytab now contains the required encryptions for the nfs/... SPN. And now NFS4 works with 5.10 / bullseye. CONCLUSION The NFS4 / SAMBA / KERBEROS setup is extremly complacated, debian's rpc.gssd is outdated or buggy and someone tried to improve security by removing something from the kernel. NFS mounts on bullseye systems may fall back to NFS3 without kerberos. Not good. PLEASE Give users a hint, a usefull error message, or fix rpc.gssd It took me a long time to indentify the reported problem and I am thankfull for a hint that I found in the univention bug tracker. Yours Jürgen -- Package-specific info: -- rpcinfo -- program vers proto port service 104 tcp111 portmapper 103 tcp111 portmapper 102 tcp111 portmapper 104 udp111 portmapper 103 udp111 portmapper 102 udp111 portmapper -- /etc/default/nfs-common -- NEED_STATD=no STATDOPTS= NEED_IDMAPD=yes NEED_GSSD=yes -- /etc/idmapd.conf -- [General] Verbosity = 0 Pipefs-Directory = /run/rpc_pipefs Domain = centauri.home [Mapping] Nobody-User = nobody Nobody-Group = nogroup -- /etc/fstab -- -- System Information: Debian Release: 10.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-0.bpo.4-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages nfs-common depends on: ii adduser 3.118 ii keyutils1.6-6 ii libc6 2.28-10
Bug#979764: Problem now understood, but potential security problem
Dear Maintainers my bug report contained the neccessary information to understand the whole problem, but it is quite complex. FIXING bullseye NFS4 Kerberos with SAMBA Probably debian uses an outdated version of rpc.gssd , SAMBA behaves 100% correctly and someone removed support for weak rpc.gssd encryption from the 5.10 kernel. In short: rpc.gssd wants a nfs/... SPN and SAMBA by default only writes weak encryption keys for nfs/... into a keytab. In SAMBA Kerberos SPNs are based on a UPN and you have to set encryption types for the UPN to let samba export better encryption keys for the SPN: net ads enctypes set root/alpha1.centauri.home 31 The samba behaviour is documented at: https://wiki.samba.org/index.php/Generating_Keytabs POTENTIAL SECURITY PROBLEM Except from the debian rpc.gssd bug, what happens is not a bug but by design. But there is no reasonable error message and backward compatibility is broken. Mount tries to use NFS3 if NFS4 fails. Does this create a security problem? Could a mount without kerberos using NFS3 happen in this case? This would break security completely. Sorry, I never used NFS3. Please close this bug if it does not create a security problem via NFS3. I am going to report the rpc.gssd / SAMBA thing as a different bug. Thanks Jürgen
