Bug#1010314: ca-certificates: Executable search ordering for OpenSSL?

[S. Egbert]

Package: ca-certificates
Version: 20210119
Severity: normal
X-Debbugs-Cc: s.egb...@sbcglobal.net

Dear Maintainer,

A group of auditors were reviewing the CA inclusion process
and have examined the `update-ca-certificates` and its code.

This issue is not about the PKI nor its certificate handling.

One auditor noticed that the ordering of looking for OpenSSL
executable file (`openssl`) seems ... counterintuitive?

I would imagine that the correct ordering for searching this `openssl`
executable file be something like:

1.  /usr/local/sbin/openssl
2.  /usr/local/bin/openssl
3.  /usr/sbin/openssl
4.  /usr/bin/openssl


The actually and current order by the latest `update-ca-certificates`
in looking for this `openssl` exectuable is currently:

1.  $CWD/openssl 
2.  /usr/local/bin/openssl
3.  /usr/local/sbin/openssl
4.  /usr/bin/openssl
5.  /usr/sbin/openssl

Please note the inversal of `sbin` and `bin`.  (The ordering of
`/usr`/`/usr/local` complies with FSSTD v2.3).

ANALYSIS

If a single-user binary (such as `openssl`) is the official and resides
within the `sbin` as a single-user file, why is `update-ca-certificates` 
looking to 
circumvent this official binary with something outside of `sbin`?

Please note that I did not say 'system binary' here that is often
mistaken for `sbin`.

In these transitory age (of Fedora squeezing `/sbin` into `/usr/bin`)
why would an auditor want to use the `bin` firstly before the `sbin`
for finding the 'official' executable?

What gain of system integrity can be had by evoking the non-single-user
`bin`-variant before the single-user `sbin`-variant?


AUDITOR ALERT: As an unrelated note but for auditors especially in area
of CA certificates, auditors should be forewarned that the 
current (`$CWD`) directory should be empty before conducting their 
examination effort using `openssl` 
executable by others (most notably and currently the `update-ca-certificates`).


Of course, I am not the UNIX expert here but merely a multi-decade 
user of UNIX.  This bug report is merely to point out if this 
inversal of `sbin`/`bin` executable lookup is
the standard expected way of doing searches for a specific executable file.


-- System Information:
Debian Release: 11.3
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ca-certificates depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  openssl1.1.1n-0+deb11u1

ca-certificates recommends no packages.

ca-certificates suggests no packages.

-- debconf information:
  ca-certificates/trust_new_crts: yes
  ca-certificates/title:
  ca-certificates/new_crts:
  ca-certificates/enable_crts: mozilla/ACCVRAIZ1.crt, 
mozilla/AC_RAIZ_FNMT-RCM.crt, mozilla/Actalis_Authentication_Root_CA.crt, 
mozilla/AffirmTrust_Commercial.crt, mozilla/AffirmTrust_Networking.crt, 
mozilla/AffirmTrust_Premium.crt, mozilla/AffirmTrust_Premium_ECC.crt, 
mozilla/Amazon_Root_CA_1.crt, mozilla/Amazon_Root_CA_2.crt, 
mozilla/Amazon_Root_CA_3.crt, mozilla/Amazon_Root_CA_4.crt, 
mozilla/Atos_TrustedRoot_2011.crt, 
mozilla/Autoridad_de_Certificacion_Firmaprofesional_CIF_A62634068.crt, 
mozilla/Baltimore_CyberTrust_Root.crt, mozilla/Buypass_Class_2_Root_CA.crt, 
mozilla/Buypass_Class_3_Root_CA.crt, mozilla/CA_Disig_Root_R2.crt, 
mozilla/Certigna.crt, mozilla/Certigna_Root_CA.crt, 
mozilla/certSIGN_ROOT_CA.crt, mozilla/certSIGN_Root_CA_G2.crt, 
mozilla/Certum_Trusted_Network_CA_2.crt, mozilla/Certum_Trusted_Network_CA.crt, 
mozilla/CFCA_EV_ROOT.crt, mozilla/Chambers_of_Commerce_Root_-_2008.crt, 
mozilla/Comodo_AAA_Services_root.crt, 
mozilla/COMODO_Certification_Authority.crt, 
mozilla/COMODO_ECC_Certification_Authority.crt, 
mozilla/COMODO_RSA_Certification_Authority.crt, 
mozilla/Cybertrust_Global_Root.crt, mozilla/DigiCert_Assured_ID_Root_CA.crt, 
mozilla/DigiCert_Assured_ID_Root_G2.crt, 
mozilla/DigiCert_Assured_ID_Root_G3.crt, mozilla/DigiCert_Global_Root_CA.crt, 
mozilla/DigiCert_Global_Root_G2.crt, mozilla/DigiCert_Global_Root_G3.crt, 
mozilla/DigiCert_High_Assurance_EV_Root_CA.crt, 
mozilla/DigiCert_Trusted_Root_G4.crt, mozilla/DST_Root_CA_X3.crt, 
mozilla/D-TRUST_Root_Class_3_CA_2_2009.crt, 
mozilla/D-TRUST_Root_Class_3_CA_2_EV_2009.crt, mozilla/EC-ACC.crt, 
mozilla/emSign_ECC_Root_CA_-_C3.crt, mozilla/emSign_ECC_Root_CA_-_G3.crt, 
mozilla/emSign_Root_CA_-_C1.crt, mozilla/emSign_Root_CA_-_G1.crt, 
mozilla/Entrust.net_Premium_2048_Secure_Server_CA.crt, 
mozilla/Entrust_Root_Certification_Authority.crt, 
mozilla/Entrust_Root_Certification_Authority_-_EC1.crt, 

Bug#995793: Info received (Bug#995793: exim4-base: /tmp partition has noexec mount option; exim4-base fails)

[S Egbert]

Actual workaround is to remove ‘noexec” from both /tmp and /var. Tested it 
working without “noexec” mount options on ‘apt upgrade exim4-base’ to versio 
‘4.94.2-7’

This makes it like a major work-stoppage of dealing with 1,000s of those 
hardened Debian systems. 

> On Oct 5, 2021, at 4:00 PM, Debian Bug Tracking System 
>  wrote:
> 
> Thank you for the additional information you have supplied regarding
> this Bug report.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> Your message has been sent to the package maintainer(s):
> Exim4 Maintainers 
> 
> If you wish to submit further information on this problem, please
> send it to 995...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 
> -- 
> 995793: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995793
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#995793: exim4-base: /tmp partition has noexec mount option; exim4-base fails

[S Egbert]

workaround of removing ‘noexec’ from /tmp partition in /etc/fstab still doesn’t 
work.  

00 [TERM="linux" TTY="/dev/tty1" COLUMNS="80" LINES="25"]
[?2004hroot@circa:~# apt upgrade exim4-base
[?2004l

Reading package lists... 0%

Reading package lists... 100%

Reading package lists... Done


Building dependency tree... 0%

Building dependency tree... 0%

Building dependency tree... 50%

Building dependency tree... 50%

Building dependency tree... Done


Reading state information... 0% 

Reading state information... 0%

Reading state information... Done


Calculating upgrade... 0%

Calculating upgrade... 10%

Calculating upgrade... Done

The following packages were automatically installed and are no longer required:
  libevent-core-2.1-7 libevent-pthreads-2.1-7 libopts25 sntp
Use 'apt autoremove' to remove them.
The following packages will be upgraded:
  exim4-base exim4-config tzdata
3 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
8 not fully installed or removed.
Need to get 0 B/1,906 kB of archives.
After this operation, 2,784 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Reading changelogs... 25%
Reading changelogs... 50%
Reading changelogs... 100%
  
Reading changelogs... Done
Preconfiguring packages ...

78(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 181409 files and directories currently installed.)
Preparing to unpack .../tzdata_2021a-1+deb11u1_all.deb ...
7Progress: [  0%] 
[..] 
87Progress: [  5%] 
[##] 8Unpacking tzdata 
(2021a-1+deb11u1) over (2021a-1) ...
dpkg (subprocess): unable to execute old tzdata package post-removal script 
(/var/lib/dpkg/info/tzdata.postrm): Permission denied
dpkg: warning: old tzdata package post-removal script 
subprocess returned error exit status 2
dpkg: trying script from the new package instead ...
dpkg (subprocess): unable to execute new tzdata package post-removal script 
(/var/lib/dpkg/tmp.ci/postrm): Permission denied
dpkg: error processing archive 
/var/cache/apt/archives/tzdata_2021a-1+deb11u1_all.deb (--unpack):
 new tzdata package post-removal script subprocess returned error exit status 2
dpkg (subprocess): unable to execute new tzdata package post-removal script 
(/var/lib/dpkg/tmp.ci/postrm): Permission denied
dpkg: error while cleaning up:
 new tzdata package post-removal script subprocess returned error exit status 2
Preparing to unpack .../exim4-config_4.94.2-7_all.deb ...
7Progress: [ 10%] 
[#.] 8dpkg 
(subprocess): unable to execute new exim4-config package pre-installation 
script (/var/lib/dpkg/tmp.ci/preinst): Permission denied
dpkg: error processing archive 
/var/cache/apt/archives/exim4-config_4.94.2-7_all.deb (--unpack):
 new exim4-config package pre-installation script subprocess returned error 
exit status 2
dpkg (subprocess): unable to execute new exim4-config package post-removal 
script (/var/lib/dpkg/tmp.ci/postrm): Permission denied
dpkg: error while cleaning up:
 new exim4-config package post-removal script subprocess returned error exit 
status 2
Preparing to unpack .../exim4-base_4.94.2-7_amd64.deb ...
7Progress: [ 14%] 
[..] 8dpkg 
(subprocess): unable to execute new exim4-base package pre-installation script 
(/var/lib/dpkg/tmp.ci/preinst): Permission denied
dpkg: error processing archive 
/var/cache/apt/archives/exim4-base_4.94.2-7_amd64.deb (--unpack):
 new exim4-base package pre-installation script subprocess returned error exit 
status 2
dpkg (subprocess): unable to execute new exim4-base package post-removal script 
(/var/lib/dpkg/tmp.ci/postrm): Permission denied
dpkg: error while cleaning up:
 new exim4-base package post-removal script subprocess returned error exit 
status 2
Errors were encountered while processing:
 /var/cache/apt/archives/tzdata_2021a-1+deb11u1_all.deb
 /var/cache/apt/archives/exim4-config_4.94.2-7_all.deb
 /var/cache/apt/archives/exim4-base_4.94.2-7_amd64.deb

78E: Sub-process /usr/bin/dpkg returned an error 
code (1)
[?2004hroot@circa:~# 

Bug#995793: exim4-base: /tmp partition has noexec mount option; exim4-base fails

[S Egbert]

WORKAROUND
Remove the “no exec” from /tmp mount point options in /etcfstab, reboot, then 
attempt ‘apt upgrade exim4-base’ so that Perl script for ‘exam-config’ can 
continue. 

OUTPUT of failed upgrade:

~# apt upgrade exim4-base
[?2004l

Reading package lists... 0%

Reading package lists... 100%

Reading package lists... Done


Building dependency tree... 0%

Building dependency tree... 0%

Building dependency tree... 50%

Building dependency tree... 50%

Building dependency tree... Done


Reading state information... 0% 

Reading state information... 0%

Reading state information... Done


Calculating upgrade... 0%

Calculating upgrade... 10%

Calculating upgrade... Done

The following packages were automatically installed and are no longer required:
  libevent-core-2.1-7 libevent-pthreads-2.1-7 libopts25 sntp
Use 'apt autoremove' to remove them.
The following packages will be upgraded:
  exim4-base exim4-config tzdata
3 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
8 not fully installed or removed.
Need to get 0 B/1,906 kB of archives.
After this operation, 2,784 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Reading changelogs... 25%
Reading changelogs... 50%
Reading changelogs... 100%
  
Reading changelogs... Done
Preconfiguring packages ...
Can't exec "/tmp/tzdata.config.jtoGAt": Permission denied at 
/usr/lib/x86_64-linux-gnu/perl-base/IPC/Open3.pm line 178.
open2: exec of /tmp/tzdata.config.jtoGAt configure 2021a-1 failed: Permission 
denied at /usr/share/perl5/Debconf/ConfModule.pm line 59.

78(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 181409 files and directories currently installed.)
Preparing to unpack .../tzdata_2021a-1+deb11u1_all.deb ...
7Progress: [  0%] 
[..] 
87Progress: [  5%] 
[##] 8Unpacking tzdata 
(2021a-1+deb11u1) over (2021a-1) ...
dpkg (subprocess): unable to execute old tzdata package post-removal script 
(/var/lib/dpkg/info/tzdata.postrm): Permission denied
dpkg: warning: old tzdata package post-removal script 
subprocess returned error exit status 2
dpkg: trying script from the new package instead ...
dpkg (subprocess): unable to execute new tzdata package post-removal script 
(/var/lib/dpkg/tmp.ci/postrm): Permission denied
dpkg: error processing archive 
/var/cache/apt/archives/tzdata_2021a-1+deb11u1_all.deb (--unpack):
 new tzdata package post-removal script subprocess returned error exit status 2
dpkg (subprocess): unable to execute new tzdata package post-removal script 
(/var/lib/dpkg/tmp.ci/postrm): Permission denied
dpkg: error while cleaning up:
 new tzdata package post-removal script subprocess returned error exit status 2
Preparing to unpack .../exim4-config_4.94.2-7_all.deb ...
7Progress: [ 10%] 
[#.] 8dpkg 
(subprocess): unable to execute new exim4-config package pre-installation 
script (/var/lib/dpkg/tmp.ci/preinst): Permission denied
dpkg: error processing archive 
/var/cache/apt/archives/exim4-config_4.94.2-7_all.deb (--unpack):
 new exim4-config package pre-installation script subprocess returned error 
exit status 2
dpkg (subprocess): unable to execute new exim4-config package post-removal 
script (/var/lib/dpkg/tmp.ci/postrm): Permission denied
dpkg: error while cleaning up:
 new exim4-config package post-removal script subprocess returned error exit 
status 2
Preparing to unpack .../exim4-base_4.94.2-7_amd64.deb ...
7Progress: [ 14%] 
[..] 8dpkg 
(subprocess): unable to execute new exim4-base package pre-installation script 
(/var/lib/dpkg/tmp.ci/preinst): Permission denied
dpkg: error processing archive 
/var/cache/apt/archives/exim4-base_4.94.2-7_amd64.deb (--unpack):
 new exim4-base package pre-installation script subprocess returned error exit 
status 2
dpkg (subprocess): unable to execute new exim4-base package post-removal script 
(/var/lib/dpkg/tmp.ci/postrm): Permission denied
dpkg: error while cleaning up:
 new exim4-base package post-removal script subprocess returned error exit 
status 2
Errors were encountered 

Bug#995260: chrony: Mismatched filename for UNIX socket between client and daemon

[S Egbert]

There is still a Mismatched SOCK filespec implemented by chronyd and chronyc.

The saving grace was that loopback network interface hid this bug very well and 
saved the day for nearly everyone (who is not an expert Chronyd configurer)...

That is, until the directive 'cmddeny 127.0.0.1' is configured: then one finds 
out the hard way that there is no consistent way to open the UNIX socket.  


Workaround:

Don't use 'cmddeny 127.0.0.1' setting for now until the filenaming convention
for its socket file specification becomes synchronized between Chrony client 
and server.



STRACES
---
In all straces below, the config directive is:

  cmddeny 127.0.0.1


Client CLI Fallback method (default)

This following strace details the default operation of ordinary chronyc CLI 
client operation, specifically to send a 'sources' CLI command with hope to 
receive a list of NTP servers.

This shell invocation did NOT use an '-h' option, fallback mechanism to other 
communcation channel methods werre done:  
* Socket failed,  (this bug report)
* IPv4 loopback failed (due to 'cmddeny 127.0.0.1')
* IPv6 loopback failed (not sure how, but it shouldn't have happened)

#Shell Invocation
# strace -f chrony -d -d -d sources

socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_IP) = 3
socket(AF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
write(2, "Resolved 127.0.0.1 to 127.0.0.1", 31Resolved 127.0.0.1 to 127.0.0.1) 
= 31
write(2, "\n", 1
write(2, "Resolved ::1 to ::1", 19Resolved ::1 to ::1) = 19
write(2, "\n", 1
socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
unlink("/var/run/chrony/chronyc.21014.sock") = -1 ENOENT (No such file or 
directory)
write(2, "Could not remove /var/run/chrony"..., 79Could not remove 
/var/run/chrony/chronyc.21014.sock : No such file or directory) = 79
write(2, "\n", 1
bind(3, {sa_family=AF_UNIX, sun_path="/var/run/chrony/chronyc.21014.sock"}, 
110) = -1 EACCES (Permission denied)
write(2, "Could not bind Unix socket to /v"..., 84Could not bind Unix socket to 
/var/run/chrony/chronyc.21014.sock : Permission denied) = 84
write(2, "\n", 1
getsockname(3, {sa_family=AF_UNIX}, [112->2]) = 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
write(2, "Opened UDPv4 socket fd=3 remote="..., 45Opened UDPv4 socket fd=3 
remote=127.0.0.1:323) = 45
write(2, "Could not receive message fd=3 :"..., 51Could not receive message 
fd=3 : Connection refused) = 51
write(2, "\n", 1
getsockname(3, {sa_family=AF_INET, sin_port=htons(34899), 
sin_addr=inet_addr("127.0.0.1")}, [112->16]) = 0
socket(AF_INET6, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
read(4, "# /etc/nsswitch.conf\n#\n# Example"..., 4096) = 542
read(4, "", 4096)   = 0
read(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0003\0\0\0\0\0\0"..., 
832) = 832
read(4, "# Internet (IP) protocols\n#\n# Up"..., 4096) = 2932
setsockopt(3, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0
write(2, "Opened UDPv6 socket fd=3 remote="..., 41Opened UDPv6 socket fd=3 
remote=[::1]:323) = 41
write(2, "\n", 1
write(2, "Sent data fd=3 len=32", 21Sent data fd=3 len=32)   = 21
write(2, "\n", 1
write(2, "Timeout 1.00 seconds", 24Timeout 1.00 seconds) = 24
write(2, "\n", 1
write(2, "Could not receive message fd=3 :"..., 51Could not receive message 
fd=3 : Connection refused) = 51
write(2, "\n", 1
write(2, "Sent data fd=3 len=32", 21Sent data fd=3 len=32)   = 21
write(2, "\n", 1
write(2, "Timeout 2.00 seconds", 24Timeout 2.00 seconds) = 24
write(2, "\n", 1
write(2, "Could not receive message fd=3 :"..., 51Could not receive message 
fd=3 : Connection refused) = 51
write(2, "\n", 1
write(2, "Sent data fd=3 len=32", 21Sent data fd=3 len=32)   = 21
write(2, "\n", 1
write(2, "Timeout 4.00 seconds", 24Timeout 4.00 seconds) = 24
write(2, "\n", 1
write(2, "Could not receive message fd=3 :"..., 51Could not receive message 
fd=3 : Connection refused) = 51
write(2, "\n", 1
getsockname(3, {sa_family=AF_INET6, sin6_port=htons(56416), 
sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::1", _addr), 
sin6_scope_id=0}, [112->28]) = 0


Client CLI Direct Loopback method
-
The following strace uses '-h' command line option to specify the desired 
sockets, network-based, but we know that daemon has already been directed by 
'cmddeny 127.0.0.1', so no go here.

Since the CLI command line explicitly asked for '-h 127.0.0.1' there were no 
fallback mechanism to try other channel methods (UNIX socket or a non-loopback 
remote network)  

That too failed (correctly) due to 'cmddeny 127.0.0.1' directive.

#Shell Invocation
# strace -f chronyc -h 127.0.0.1 sources

socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_IP) = 3
socket(AF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3
write(2, "Resolved 127.0.0.1 to 127.0.0.1", 31Resolved 127.0.0.1 to 127.0.0.1) 
= 31
write(2, "\n", 1
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
write(2, "Opened UDPv4 socket fd=3 

Bug#995207: chrony: Using 'bindacqdevice' directive causes a SIGSYS error

[S Egbert]

.
> 
> After having stopped chronyd, please run the command below when using the
> 'bindacqdevice' directive and attach the chronyd_debug.txt file.
> 
> # strace -o chronyd_debug.txt chronyd -d -F -1

OK, I did some more testing on my so-called fix:  SO_BINDTOADDRESS define 
statement made no impact toward resolving this problem.


Once I put in the '#define SO_BINDTOADDRESS 1' statement into the 'config.h' 
that was generated by 'configure' setup tool, all the -F settings are now 
working.

'chrony -d -Fx -L-1' F0  F1  F2  F-1
* apt install chrony-4.0 OK   -   -   -
* apt source chrony-4.0  OK   -   -  OK
* git main branch HEAD   OK   -  OK   -
* development + MY FIX   OK   -  OK   - 

My fix made no difference in gitdev HEAD: Please disregard my claim that the 
SO_BINDTOADDRESS C macro we’re not being defined. 

Back to the issue on hand, I like the -F2 setting.

At this point so far, I'm open to further suggestion.

1.  Go ahead and put 4.1 into debian-unstable with -F2 default
2.  Give me more things to try.
3.  ???

Bug#995207: chrony: Using 'bindacqdevice' directive causes a SIGSYS error

[S Egbert]

Got a bit further when I myself included `#define SO_BINDTODEVICE 1` to the 
`config.h` that `configure` created.

Then I noticed that `configure` underwent a Redhat overhaul. 

Missing the maintainer’s `configure.ac` so we can’t readily fix this.  Punt 
this bug upstair.

> On Sep 29, 2021, at 9:10 AM, Vincent Blut  wrote:
> 
> Le 2021-09-28 12:54, S Egbert a écrit :
>> Trying attachment again.
> 
> Thanks. To see what happens when blocking only a small number of specific
> syscalls, could you please run the following command and attach the
> chronyd-debug.txt file?
> 
> # timeout 10 strace -o chronyd-debug.txt -e trace=setsockopt chronyd -d -F 2
> 
> Cheers,
> Vincent

Bug#995207: chrony: Using 'bindacqdevice' directive causes a SIGSYS error

[S Egbert]

Summary:
The syscall filter daemon option flag -F is the cure.

Using '-F 0' to disable the syscall filter works.  No other settings are 
workable.

A summary table:

Chrony   -- daemon flags used --
Version  -F0 -F1 -F-1
---  --  --  --
4.0-9ok  SIGSYS  SIGSYS
#83f96e  ok  SIGSYS  SIGSYS

Using the latest '/etc/systemd/system/chronyd.service' from 'examples' 
subdirectory in the Git repo does not improve the picture nor alter the summary 
table given above.

chrony: 4.0-8, Debian
chrony: git repo "development" main HEAD branch (#83f96efd), Sept 29, 2021
libseccomp2 2.5.1-1
libc6 2.31-13
Kernel: 5.10.46 - untainted
Virtualization: non-virtualized, machine-level
CPU: Intel i5-3470

Bug#995207: chrony: Using 'bindacqdevice' directive causes a SIGSYS error

[S Egbert]

>> Trying attachment again.
> 
> Thanks. To see what happens when blocking only a small number of specific
> syscalls, could you please run the following command and attach the
> chronyd-debug.txt file?
> 
> # timeout 10 strace -o chronyd-debug.txt -e trace=setsockopt chronyd -d -F 2

setsockopt(3, SOL_IP, IP_PKTINFO, [1], 4) = 0
setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(3, SOL_SOCKET, SO_REUSEPORT, [1], 4) = 0
setsockopt(3, SOL_IP, IP_FREEBIND, [1], 4) = 0
setsockopt(4, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0
setsockopt(4, SOL_IPV6, IPV6_RECVPKTINFO, [1], 4) = 0
setsockopt(4, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(4, SOL_SOCKET, SO_REUSEPORT, [1], 4) = 0
setsockopt(4, SOL_IP, IP_FREEBIND, [1], 4) = 0
setsockopt(7, SOL_IP, IP_PKTINFO, [1], 4) = 0
setsockopt(7, SOL_SOCKET, SO_BINDTODEVICE, "enp5s0\0", 7) = ?
+++ killed by SIGSYS +++

Bug#995260: closed by Vincent Blut (Re: Bug#995260: chrony: Mismatched filename for UNIX socket between client and daemon)

[S Egbert]

so why did it not use the Unix socket but fell back to 127.0.0.1 approach?

i wonder what happens if i do ‘cmddeny all’?

Bug#995207: Acknowledgement (chrony: Using 'bindacqdevice' directive causes a SIGSYS error)

[S Egbert]

Trying attachment again.

It failed under iPhone 14.5.
Should succeed with Thunderbird/macOS

# ps auxwww | grep chronyd
_chrony 3597  0.0  0.0  18972  3696 ?S11:00   0:00 
/usr/sbin/chronyd -F 1 -L 0
_chrony 3598  0.0  0.0  10780  2984 ?S11:00   0:00 
/usr/sbin/chronyd -F 1 -L 0
root4142  0.0  0.0   6180   716 pts/0S+   12:10   0:00 grep chronyd

# systemctl restart chronyd

# ps auxwww | grep chronyd
root4156  0.0  0.0   6180   712 pts/0S+   12:11   0:00 grep chronyd

# systemctl status chronyd
chrony.service - chrony, an NTP client/server
 Loaded: loaded (/lib/systemd/system/chrony.service; enabled; vendor 
preset: enabled)
 Active: failed (Result: signal) since Tue 2021-09-28 12:11:06 EDT; 13s ago
   Docs: man:chronyd(8)
 man:chronyc(1)
 man:chrony.conf(5)
Process: 4147 ExecStart=/usr/sbin/chronyd $DAEMON_OPTS (code=exited, 
statusm 0/SUCCESS)
   Main PID: 4149 (code=killed, signal=SYS)
CPU: 36ms

Sep 28 12:11:06 localhost chronyd[4149]: chronyd version 4.0 starting (+CMDMON 
+NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 
-DEBUG)
Sep 28 12:11:06 localhost systemd[1]: chrony.service: Succeeded.
Sep 28 12:11:06 localhost chronyd[4149]: Frequency -3.305 +/- 0.025 ppm read 
from /v ar/lib/chrony/chrony.drift
Sep 28 12:11:06 localhost systemd[1]: Stopped chrony, an NTP client/server.
Sep 28 12:11:06 localhost chronyd[4149]: Using right/UTC timezone to obtain 
leap second data
Sep 28 12:11:06 localhost systemd[1]: Starting chrony, an NTP client/server...
Sep 28 12:11:06 localhost chronyd[4149]: Loaded seccomp filter
Sep 28 12:11:06 localhost systemd[1]: Started chrony, an NTP client/server.
Sep 28 12:11:06 localhost systemd[1]: 
chrony.service: Main process exited, code=kill
lines 1-19, status=31/SYS
lines 2-19 12:11:06 localhost systemd[1]: mchrony.service: Failed with 
result 'signal'.
lines 2-20 lines 2-20/20 (END)
lines 2-20/20 (END)
lines 2-20/20 (END)
# 
# # maintainer request
# strace -o chronyd_debug.txt chronyd -d -F 1
chronyd version 4.0 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER 
+SIGND +ASYNCDNS +NTS +SECHASH +IPV6 -DEBUG)
2021-09-28T16:12:06Z Frequency -3.305 +/- 0.025 ppm read from 
/var/lib/chrony/chrony.drift
2021-09-28T16:12:06Z Using right/UTC timezone to obtain leap second data
2021-09-28T16:12:06Z Loaded seccomp filter
Bad system call
# cat chronyd_debug.txt
execve("/usr/sbin/chronyd", ["chronyd", "-d", "-F", "1"], 0x7ffecfacd628 /* 18 
vars */) = 0
brk(NULL)   = 0x55a4c537d000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=45532, ...}) = 0
mmap(NULL, 45532, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f84986a7000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\362\0\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=1321344, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f84986a5000
mmap(NULL, 1323280, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f8498561000
mmap(0x7f849857, 630784, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf000) = 0x7f849857
mmap(0x7f849860a000, 626688, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0xa9000) = 0x7f849860a000
mmap(0x7f84986a3000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x141000) = 0x7f84986a3000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnettle.so.8", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@\314\0\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=290416, ...}) = 0
mmap(NULL, 292416, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f8498519000
mprotect(0x7f8498525000, 233472, PROT_NONE) = 0
mmap(0x7f8498525000, 139264, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xc000) = 0x7f8498525000
mmap(0x7f8498547000, 90112, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0x2e000) = 0x7f8498547000
mmap(0x7f849855e000, 12288, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x44000) = 0x7f849855e000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libgnutls.so.30", O_RDONLY|O_CLOEXEC) = 
3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@y\3\0\0\0\0\0"..., 832) 
= 832
fstat(3, {st_mode=S_IFREG|0644, st_size=2086552, ...}) = 0
mmap(NULL, 2094888, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f8498319000
mmap(0x7f849834d000, 1183744, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x34000) = 0x7f849834d000
mmap(0x7f849846e000, 614400, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0x155000) = 

Bug#836902: libpam0g-dev: Missing develop-variant of libpam0g 1.1.8-3.2 package

[S Egbert]

On Tue, 06 Sep 2016 20:32:46 -0400 Steve Egbert  
wrote:


Workaround to this is to downgrade the main libpam0g package to meet the 
dev-package's version:


   sudo apt-get install libpam0g=1.1.8-3.1+deb8u1+b1

>
> The following packages have unmet dependencies:
> libpam0g-dev : Depends: libpam0g (= 1.1.8-3.1+deb8u1+b1) but 1.1.8-3.2 is
> to be installed
> E: Unable to correct problems, you have held broken packages.
>
> I thought that the actual outcome should have been a successful 
install of the

> dev-variant of this libpam0g package.
>
> I think the dev package is missing.
>

Bug#777683: e1000e driver, empty TX queue after IP drop causes dev_watchdog

[S Egbert]

I too have the same problem on Debian as 3 others do.

As a former Ethernet driver developer, I noticed that the queue is empty 
when the interrupt was fired.  And that it appeared hung in the Linux 
qdisc portion at Interrupt context, to a point of having watchdog timer 
expiring.


My relevant details is:
Dell OptiPlex 980
3.16.0-4-amd64
linux/3.16.7-ckt25-2 (2016-04-08) x86_64
Intel Gigabit Ethernet 82578DM Gigabit Network Connection (rev 05)


From what I've gathered from the following potentially duplicate bug  
#798512 and Intel Community Forums:


1 - It isn't CPU-related
2.  This error happened in the following Linux kernel versions:
a. 3.16.0-4-amd64
b. 3.19.5 (source: Intel communities)
c. 4.3+70~bpo8+1
b. 3.16.7-ckt11-1
3. This error does NOT happen in the following Linux kernel versions 
(take this with a grain of salt, for we haven't a reliable repeatable 
bug inducement yet):

a. 3.16.7-ckt20-1+deb8u4
4. Intel driver used but still have error
   b. 3.3.3-NAPI
5. Intel hardware having this problem
  a. Intel I217-V (rev 04) (onboard) (has lspci SERR-)
  b. Intel 82578DM (rev 05) (onboard)  (has lspci SERR+)
  c. Intel Corporation 82579V Gigabit Network Connection (rev 05) (onboard)
6. Linux network
   a.  eth0:  mtu 1500 qdisc 
pfifo_fast state UP group default qlen 1000
   b. eth0:  mtu 1500 qdisc pfifo_fast 
master br0 state UP mode DEFAULT group default qlen 1000



So far, common thread of the alike problems is the following (more 
reports will eliminate a few):

1.  e1000e driver
2.  ip link using 'qdisc' and 'pfifo_fast' option
2.  onboard Ethernet (PCI-related?)
3. Starting at Linux 3.16.0
4.  IP outgoing packets dropped was non-zero (mostly 32 packets)
4.  share similar call stack backtrace:

Bug #777683 call stack backtrace

[ 295.041406]  [] ? dump_stack+0x41/0x51 [ 
295.041417] [] ? warn_slowpath_common+0x77/0x90 [ 
295.041420] [] ? warn_slowpath_fmt+0x4c/0x50 [ 
295.041425] [] ? mod_timer+0x127/0x1e0 [ 295.041430] 
[] ? dev_watchdog+0x236/0x240 [ 295.041433] 
[] ? dev_graft_qdisc+0x70/0x70 [ 295.041436] 
[] ? call_timer_fn+0x31/0x100 [ 295.041439] 
[] ? dev_graft_qdisc+0x70/0x70 [ 295.041442] 
[] ? run_timer_softirq+0x209/0x2f0 [ 295.041445] 
[] ? __do_softirq+0xf1/0x290 [ 295.041448] 
[] ? irq_exit+0x95/0xa0 [ 295.041451] 
[] ? smp_apic_timer_interrupt+0x45/0x60 [ 295.041455] 
[] ? apic_timer_interrupt+0x6d/0x80 [ 295.041456] 
 [] ? get_next_timer_interrupt+0x1d6/0x250 [ 
295.041465] [] ? cpuidle_enter_state+0x4f/0xc0 [ 
295.041468] [] ? cpuidle_enter_state+0x48/0xc0 [ 
295.041472] [] ? cpu_startup_entry+0x2f8/0x400 [ 
295.041475] [] ? start_kernel+0x492/0x49d [ 
295.041478] [] ? set_init_arg+0x4e/0x4e [ 295.041480] 
[] ? early_idt_handlers+0x120/0x120 [ 295.041483] 
[] ? x86_64_start_kernel+0x14d/0x15c [ 295.041485] 
---[ end trace aaf46f7eeccba58f ]--- [ 295.041502] e1000e :00:19.0 
eth-office: Reset adapter unexpectedly


Intel Community Forums (Intel 3.3.3-NAPI driver):
(source: https://communities.intel.com/message/305442#305442)

[] ? dump_stack+0x40/0x57
[] ? warn_slowpath_common+0x81/0xb0
[] ? warn_slowpath_fmt+0x5c/0x80
[] ? dev_watchdog+0x229/0x240
[] ? dev_deactivate_queue.constprop.34+0x60/0x60
[] ? call_timer_fn+0x30/0xf0
[] ? dev_deactivate_queue.constprop.34+0x60/0x60
[] ? run_timer_softirq+0x17d/0x2b0
[] ? __do_softirq+0x107/0x270
[] ? irq_exit+0x86/0x90
[] ? smp_apic_timer_interrupt+0x3e/0x50
[] ? apic_timer_interrupt+0x82/0x90

[] ? cpuidle_enter_state+0xe8/0x220
[] ? cpuidle_enter_state+0xc3/0x220
[] ? cpu_startup_entry+0x294/0x350
[] ? start_secondary+0x150/0x190

Debian Bug #798512

] ? warn_slowpath_common+0x77/0x90
] ? warn_slowpath_fmt+0x4c/0x50
] ? mod_timer+0x127/0x1e0
] ? dev_watchdog+0x236/0x240
] ? dev_graft_qdisc+0x70/0x70
] ? call_timer_fn+0x31/0x100
] ? dev_graft_qdisc+0x70/0x70
] ? run_timer_softirq+0x209/0x2f0
] ? __do_softirq+0xf1/0x290
] ? irq_exit+0x95/0xa0

My /var/log/message (3.6.14):
dmesg: e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
dmesg: e1000e :00:19.0: Interrupt Throttling Rate (ints/sec) set to 
dynamic conservative mode

dmesg: e1000e :00:19.0 eth0: Detected Hardware Unit Hang:
May 24 18:44:55 sandbay kernel: [  840.766377]   
[] ? dump_stack+0x5d/0x78
May 24 18:44:55 sandbay kernel: [  840.766391] [] ? 
warn_slowpath_common+0x77/0x90
May 24 18:44:55 sandbay kernel: [  840.766396] [] ? 
warn_slowpath_fmt+0x4c/0x50
May 24 18:44:55 sandbay kernel: [  840.766410] [] ? 
dev_watchdog+0x236/0x240
May 24 18:44:55 sandbay kernel: [  840.766418] [] ? 
dev_graft_qdisc+0x70/0x70
May 24 18:44:55 sandbay kernel: [  840.766424] [] ? 
call_timer_fn+0x31/0x100
May 24 18:44:55 sandbay kernel: [  840.766435] [] ? 
dev_graft_qdisc+0x70/0x70
May 24 18:44:55 sandbay kernel: [  840.766439] [] ? 
run_timer_softirq+0x209/0x2f0
May 24 18:44:55 sandbay kernel: [  840.766444] [] ? 
__do_softirq+0xf1/0x290
May 24 18:44:55 sandbay kernel: [