Bug#994682: Debian 12 Bookworm
I have modified the patches to work with Debian 12 Bookworm.
Most noticeable, the "poweroff" command must now be called with the parameter
"-f" to switch off the system while waiting for an input.--- orig/functions 2023-06-12 19:44:03.169739289 +0200
+++ /usr/lib/cryptsetup/functions 2023-06-12 19:45:25.780386107 +0200
@@ -83,6 +83,7 @@
CRYPTTAB_OPTION_keyslot \
CRYPTTAB_OPTION_header \
CRYPTTAB_OPTION_tcrypthidden \
+ CRYPTTAB_OPTION_timeout \
CRYPTTAB_OPTION_same_cpu_crypt \
CRYPTTAB_OPTION_submit_from_crypt_cpus \
CRYPTTAB_OPTION_no_read_workqueue \
@@ -186,7 +187,7 @@
fi
;;
# numeric options >=0
-offset|skip|tries|keyslot|keyfile-offset)
+offset|skip|tries|keyslot|keyfile-offset|timeout)
if ! printf '%s' "${VALUE-}" | grep -Exq "[0-9]+"; then
return 1
fi
--- /usr/share/initramfs-tools/scripts/local-top/cryptroot.orig 2023-04-21 00:54:29.0 +0200
+++ /usr/share/initramfs-tools/scripts/local-top/cryptroot 2023-06-12 19:38:06.706673696 +0200
@@ -148,8 +148,16 @@
fi
fi
-local count=0 maxtries="${CRYPTTAB_OPTION_tries:-3}" fstype vg rv
+local count=0 maxtries="${CRYPTTAB_OPTION_tries:-3}" poweroffpid=0 fstype vg rv
while [ $maxtries -le 0 ] || [ $count -lt $maxtries ]; do
+if [ "${CRYPTTAB_OPTION_timeout:-0}" -gt 15 ]; then
+# Power down if not key has been entered within $timeout seconds.
+# Ignore values below 15 seconds to give the user a chance
+# to enter his passphrase in case of a typo in /etc/crypttab.
+cryptsetup_message "Timeout in $CRYPTTAB_OPTION_timeout seconds"
+ (sleep "$CRYPTTAB_OPTION_timeout" && cryptsetup_message "poweroff" && /usr/sbin/poweroff -f) &
+poweroffpid=$!
+fi
if [ -z "${CRYPTTAB_OPTION_keyscript+x}" ] && [ "$CRYPTTAB_KEY" != "none" ]; then
# unlock via keyfile
unlock_mapping "$CRYPTTAB_KEY"
@@ -159,6 +167,9 @@
fi
rv=$?
count=$(( $count + 1 ))
+if [ "$poweroffpid" -gt 0 ]; then
+kill "$poweroffpid"
+fi
if [ $rv -ne 0 ]; then
cryptsetup_message "ERROR: $CRYPTTAB_NAME: cryptsetup failed, bad password or options?"
Bug#994682: cryptsetup-initramfs: Poweroff timeout for cryptroot
Hello Chris, > a) How does a laptop turn on unintentionally? ;-) It happens from time to time on my Dell Latitude 9420. I've shut the system down at evening and later (or the next morning) I saw that the display was on and waiting for the passphrase. It even happened twice when it was stored in my laptop case. It seems that this problem is sporadically seen on Dell laptops, maybe a hardware fault. But it could also happen on any other laptop if you accidentally selected reboot instead of poweroff and closed the lid, or if the laptop has a power-on-lid feature. > Consider that such a system would constantly be powered on > automatically (Wake-On-LAN or similar features of servers)... in such a > case, if cryptroot keyscript wouldn't finish in due time (e.g. because > no one enters the passphrase or so), it might end up in a > powerup/powerdown cycle... which is probably of no good for the > hardware. Well, then don't enable it for servers? The patch doesn't add a timeout by default, only if defined in crypttab. Best Regards, Roland
Bug#994682: cryptsetup-initramfs: Poweroff timeout for cryptroot
Package: cryptsetup-initramfs
Version: 2.3.5
Severity: wishlist
If someone is using an encrypted root fs, and the laptop unintentionally turns
on, it would wait for the passphrase until the battery is empty (that's what
happened to me yesterday).
For this reason please let me suggest to add a timeout option into crypttab,
which will turn the system off if the passphrase (or the key) has not been
provided within the given period of time.
I've added a proof-of-concept patch to /usr/share/initramfs-tools/scripts/
local-top/cryptroot and /usr/lib/cryptsetup/functions which introduced this
feature.
I know that there is a similar report #509070 from 2008, but while that
reports suggests to skip the device for convenience reasons, my report is to
protecting the system's battery.
Best regards,
Roland--- /usr/lib/cryptsetup/functions 2021-09-19 12:28:43.194023501 +0200
+++ /usr/lib/cryptsetup/functions 2021-09-19 12:58:51.302852958 +0200
@@ -81,7 +81,8 @@
CRYPTTAB_OPTION_keyscript \
CRYPTTAB_OPTION_keyslot \
CRYPTTAB_OPTION_header \
- CRYPTTAB_OPTION_tcrypthidden
+ CRYPTTAB_OPTION_tcrypthidden \
+ CRYPTTAB_OPTION_timeout
# use $_CRYPTTAB_OPTIONS not $CRYPTTAB_OPTIONS as options values may
# contain '\054' which is decoded to ',' in the latter
for x in $_CRYPTTAB_OPTIONS; do
@@ -177,7 +178,7 @@
fi
;;
# numeric options >=0
-offset|skip|tries|keyslot|keyfile-offset)
+offset|skip|tries|keyslot|keyfile-offset|timeout)
if ! printf '%s' "${VALUE-}" | grep -Exq "[0-9]+"; then
return 1
fi
--- /usr/share/initramfs-tools/scripts/local-top/cryptroot 2021-09-19 11:51:52.149584290 +0200
+++ /usr/share/initramfs-tools/scripts/local-top/cryptroot 2021-09-19 13:11:29.646265591 +0200
@@ -155,8 +155,16 @@
fi
fi
-local count=0 maxtries="${CRYPTTAB_OPTION_tries:-3}" fstype vg rv
+local count=0 maxtries="${CRYPTTAB_OPTION_tries:-3}" poweroffpid=0 fstype vg rv
while [ $maxtries -le 0 ] || [ $count -lt $maxtries ]; do
+if [ "${CRYPTTAB_OPTION_timeout:-0}" -gt 15 ]; then
+# Power down if not key has been entered within $timeout seconds.
+# Ignore values below 15 seconds to give the user a chance
+# to enter his passphrase in case of a typo in /etc/crypttab.
+cryptsetup_message "Timeout in $CRYPTTAB_OPTION_timeout seconds"
+ (sleep "$CRYPTTAB_OPTION_timeout" && poweroff) &
+poweroffpid=$!
+fi
if [ -z "${CRYPTTAB_OPTION_keyscript+x}" ] && [ "$CRYPTTAB_KEY" != "none" ]; then
# unlock via keyfile
unlock_mapping "$CRYPTTAB_KEY"
@@ -166,6 +174,9 @@
fi
rv=$?
count=$(( $count + 1 ))
+if [ "$poweroffpid" -gt 0 ]; then
+kill "$poweroffpid"
+fi
if [ $rv -ne 0 ]; then
cryptsetup_message "ERROR: $CRYPTTAB_NAME: cryptsetup failed, bad password or options?"
Bug#902620: certbot.service should not use root privileges
Package: certbot Version: 0.10.2-1 Severity: serious Tags: security Justification: 5.b Dear Maintainer, certbot.service is configured to be executed with root privileges. This leads to a potential attack vector while renewing certificates, especially when using the 'standalone' authenticator. For most setups it should be sufficient to run 'certbot --renew' as an unprivileged user 'certbot'. This would require the following changes in the default setup: - /etc/letsencrypt and /var/letsencrypt must be owned and writable by 'certbot' - for standalone authenticator, the default port has to be changed to an unprivileged one (e.g. 8080). - for webroot authenticator, a seperate directory for the acme challenge owned and writable by 'certbot' must be created (e.g. /etc/letsencrypt/acme-challenge) and an Apache rewrite rule must redirect requests to this directory: RewriteRule ^/(\.well-known/acme-challenge/.*)$ \ /etc/letsencrypt/acme-challenge$1 [L] AllowOverride none Require all granted For nginx, a similar configuration would be required. -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages certbot depends on: ii init-system-helpers 1.48 ii python 2.7.13-2 ii python-certbot 0.10.2-1 certbot recommends no packages. Versions of packages certbot suggests: pn python-certbot-apache pn python-certbot-doc -- no debconf information
Bug#737921: [TLS1.2] gnutls only likes SHA1 and SHA256 certificates
Hallo, I agree with Tobias, this is a major problem. Best regards, Roland Tapken signature.asc Description: This is a digitally signed message part.
