Whonix Linux Installer - Development Discussion

Development
181

Many functions that are used in the installer are now on separate files in helper-scripts, see commits made this week only for related changes.

A Kicksecure shell library for logging, discovering OS, running commands are root etc.

1 Like
182

This was merged and works great. Many thanks!

In result, a lot generic code such as for logging, root check can now be re-used in other projects.

183
  • Improved Secure Boot support. The Whonix Linux installer now checks if Secure Boot DKMS signing key enrollment has been done. If necessary and not done, it will advice the user to do so. → Secure Boot - Kicksecure
  • Operating system package upgrade availability test has been improved.

Uploaded just now.

184

Potential bug:

185

This was resolved.

186
187

Fixed.

Any idea why this was not caught by the CI?

188
189

Merged.

190

Two output related bugs.

whonix-xfce-installer-cli: [NOTICE]: \033[4mInstaller:\033[24m \033[1m’Whonix Xfce for VirtualBox Installer’\033[22m

whonix-xfce-installer-cli: [NOTICE]: Command executing: $ timeout–foreground2700rsync-ssl–no-motd–progress–verbose–verbose–timeout600–compress–partial–max-size3Grsync://whonix.org/whonix/ova/17.2.2.5/Whonix-Xfce-17.2.2.5.ova/home/user/dist-installer-cli-download

191

More of the same issues.

whonix-xfce-installer-cli: [NOTICE]: \033[4mVirtualBox Installation Result:\033[24m ‘success’

whonix-xfce-installer-cli: [NOTICE]: \033[4mVirtualBox Startup Check:\033[24m User declined to start VirtualBox via ‘–no-boot’ option.

whonix-xfce-installer-cli: [NOTICE]: \033[4mVM Startup Check:\033[24m User declined to start Virtual Machine(s) via ‘–no-boot’ option.

whonix-xfce-installer-cli: [NOTICE]: Installer Result: \033[32m\033[1m’SUCCESS’\033[22m\033[0m

192

The problem is due to the safer mode used in the log function when using printf with %s, commits that introduced it:

Although it is safer to print everything raw, not allowing untrusted input to expand, it is not allowing any input at all to expand.

log() has the following format: log mode message. It is printed with printf '%s%b%s\n' "${log_source_script}" "${log_level_colorized}" "${log_content}" >&2.

So, only log_level_colorized is allowed to expand with %b, while log_source_script and log_content can’t expand with %s.

In the case of wanting to make log_content be formatted with underline, it won’t work, as well as printing any other escape characters with it, which is indeed safer.

How to fix this issue by allowing formatting in the log content but still keeping untrusted input safe to be printed, I don’t know.

193

My first thought is that we have to parse escape codes of some sort if we’re going to be able to format or color messages at all. If we’re going to do that anyway, the solution is going to involve either translating formatting markers into escape codes, or sanitizing escape codes. Of the two, it’s probably easier to sanitize the escape codes - helper-scripts/usr/libexec/helper-scripts/get_colors.sh provides a convenient whitelist of all the escape codes we want to preserve, so we can just say:

  • For each byte, if it is:
    • User-visible ASCII (i.e. a value between 0x20 and 0x7E inclusive, plus 0x09 for tab and 0x0A for newline): leave it.
    • Escape (0x1B):
      • If it is immediately followed by a whitelisted code, leave it.
      • Otherwise, strip it, it’s possibly/likely malicious.
    • Anything else: strip it.

Not sure if this can be efficiently implemented in Bash, but it’s probably doable in Python without too much trouble.

1 Like
194
1 Like
195
1 Like