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

2022-04-29 Thread Julien Cristau
Control: tag -1 moreinfo unreproducible

On Thu, Apr 28, 2022 at 12:38:28PM -0400, S. Egbert wrote:
> A group of auditors were reviewing the CA inclusion process

I.. don't know what the above means.

> 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).
> 
update-ca-certificates doesn't specify a path for openssl, it relies on
$PATH being set, like most things.

I don't see a bug here.

Cheers,
Julien



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

2022-04-28 Thread 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, 
mozilla/Entrust_Root_Certification_A