ToDo for Developers

From Kicksecure
< Dev
Jump to navigation Jump to search

TODO

TODO DEV[edit]

review and test IPv6 support pull requests[edit]

debian grub-pc with grub-efi co-installation issue bug report[edit]

  • please check if one already exists, report a bug or feature request against Debian for grub-pc with grub-efi co-install-ability

legacy-dist - enable GRUB force_efi_extra_removable[edit]

debconf-set-selections <<< 'grub-efi-arm64 grub2/force_efi_extra_removable

user-sysmaint-split - Qubes support[edit]

  • user-sysmaint-split - useful to install in Qubes for Kicksecure or Qubes-Whonix? Probably yes, due to sudo hardening.
  • Plan for Kicksecure-Qubes and Qubes-Whonix-Workstation?
    • No longer install qubes-core-agent-passwordless-root by default.
    • Install user-sysmaint-split by default in new templates.
    • Users could not really use account sysmaint due to missing X server. Instead, user needs to use a Qubes Root Console.
  • Plan for Qubes-Whonix-Gateway?
  • user documentation
  • suggestions for create user `admin` by default and add user `admin` to group `sudo` by defaultarchive.org?
  • /usr/bin/passwordless-root needs fixes?

Qubes - Selective sudo Access[edit]

qubes-template-kicksecure[edit]

kicksecure-meta-packages fixes for qubes-template-kicksecure[edit]

  • packages in https://github.com/Whonix/qubes-whonix/blob/master/debian/controlarchive.org need to be re-implemented in kicksecure-meta-packages as appropriate
  • Fixes needed (NOT YET DONE):
    • Add qubes-core-agent-networking, qubes-core-agent-thunar, and xfce4-settings to package kicksecure-qubes-gui.
    • Add user-sysmaint-split to template code.
      • Requires user-sysmaint-split to be published in Kicksecure's repos
        • Patrick: Done.

Strong Linux User Account Isolation wiki page - add Wayland considerations[edit]

  • edit Strong Linux User Account Isolation and point out differences in X11 versus Wayland in applicable chapters
  • For example, chapter Console Login Attacks currently only discusses X11. Please separate the description of X11 from Wayland.
    • Done, did necessary research and added info to the wiki.
  • please search with browser website internal search for all mentions of X11 and add Wayland equivalents documentation

calamares dual legacy + efi booting support[edit]

investigate Debian Rolling[edit]

  • investigate why Debian Rolling initiative failed
    • From initial research:
      • Lots of disagreement about how exactly to implement it, although https://lists.debian.org/debian-devel/2011/05/msg00275.htmlarchive.org had a very large amount of positive feedback compared to other proposals
      • Limited manpower, no one appears to have tried to actually do it
      • Need to cope with the activity occurring in Debian's unstable and testing repositories, which have some turbulence and can cause issues if one isn't careful
      • Likely worth trying to resurrect
  • contact people involved previously, if that makes sense
  • suggest prospective developers
  • Started to write tooling for this: https://github.com/ArrayBolt3/drkarchive.org Very incomplete, nowhere near usable. Will keep developing this.

implement sudoless[edit]

user-sysmaint-split - enable user-sysmaint-split by default for Xfce version[edit]

   #--sysmaint-enable \\
   #--unrestricted-admin-enable \\
  • and for VM images as "loose packages"
  • not for Whonix-Gateway?

default password[edit]

  • rationale: virtual console based login attempts. An attacker could connect a keyboard to a server to login.
  • review wiki: Default Passwords
  • helper-scripts: add a tool that looks user accounts with empty passwords, if feasible
  • GUI ISO: calamares.
    • link to documentation
    • choices:
      • default: none (user must choose)
      • passwordless
      • set a password
  • CLI ISO: non-existent, therefore non-issue for now
  • GUI VM images: A setup-wizard-dist popup should explain this.
  • CLI: an INFO message after login if there are any unlocked passwordless accounts

ISO - use variable flavor_meta_packages_to_install[edit]

  • using already existing variable flavor_meta_packages_to_install would simplify modifications

audio[edit]

audio generally[edit]

VirtualBox Intel HD Audio and PipeWire Incompatibility / Audio broken after increasing ram to 5 GB / No sound after latest updates - PipeWire Bug?[edit]

live-build - test lb config --dm-verity[edit]

  • Does the ISO still function if build with lb config --dm-verity?
  • Does it break apt-get install pkg-name? It might not break it due to overlayfs.
  • Lacks live-build support when used with dracut:
    • lb config won't even run if you try to enable verity and dracut at the same time, unless you override live-build by commenting that sanity check out
    • The ISO won't build initially because the dm-verity building code is trying to find the live filesystem in the wrong location
    • dracut isn't configured to include systemd-veritysetup-generator, needed for verifying the root FS in the first place
    • No kernel command line options are added to the ISO for verity setup

Split the security-misc into security-misc-shared, security-misc-desktop and security-misc-server[edit]

Kicksecure Firewall[edit]

https://forums.kicksecure.com/t/kicksecure-firewall/378/10archive.org

Meta Packages, Kicksecure, Whonix - Desktop versus Server[edit]

https://forums.kicksecure.com/t/meta-packages-kicksecure-desktop-versus-kicksecure-server/415archive.org

Secure Mount Options for better Security Hardening[edit]

wipe video RAM[edit]

# zero video RAM to prevent leakage
# see (CC BY-SA 4.0): https://www.adlerweb.info/blog/2012/06/20/nvidia-x-org-video-ram-information-leak
export R600_DEBUG=zerovram;
export AMD_DEBUG=zerovram;
export RADV_DEBUG=zerovram;
  • if doable with reasonable effort

Tor 0.4.8.9 broken in combination with vanguards[edit]

VirtualBox serial console[edit]

KVM related[edit]

KVM - 3D Graphics Acceleration - SPICE - Testing - drm[edit]

KVM - 3D Graphics Acceleration - Performance Test - Display SDL[edit]

KVM - 3D Graphics Acceleration - Performance Test - Display GDK[edit]

machine-id research[edit]

  • in preparation for the next task
  • please read prior discussions
  • https://www.whonix.org/wiki/Protocol-Leak-Protection_and_Fingerprinting-Protection#Identifiers_Design_Goalsarchive.org
  • https://forums.whonix.org/t/revisit-handling-of-var-lib-dbus-machine-id/18827archive.org
  • https://forums.whonix.org/t/anonymize-etc-machine-id/7721archive.org
  • https://gitlab.tails.boum.org/tails/tails/-/issues/7100archive.org
  • nowadays implemented in dist-base-files
    • ./packages/kicksecure/dist-base-files/var/lib/dbus/machine-id
    • ./packages/kicksecure/dist-base-files/etc/machine-id
  • but maybe needs to be moved back to anon-base-files when porting to Debian trixie? (hard to migrate within the same release codename)
  • The machine-id files should not be shipped by a package. They are intended to be generated, not hardcoded, thus Debian's code is probably not going to cope well when a package ships these files. Case in point, live-build deleting them to avoid machines with duplicate IDs in the wild, when we want machines with duplicate IDs in the wild.
  • Calamares is designed to write the machine-id files at instalation time. It has a dedicated module for this purpose. However, it does not permit specifying a hardcoded machine-id other than a literal "uninitialized" value or an empty file. So we will have to resort to using a shellprocess for Whonix-Host that will detect when Whonix is in use, and overwrite the machine-id files with a static machine-id. Calamares is the proper location to do this at IMO, since it's designed for this, systemd's docs suggest using the installer for this, and I fear we could run into problems trying to do this on first boot with a systemd unit.
    • Patrick: Please implement.
    • Patrick: Note, Whonix VMs are built using grml-debootstrap. While using a package to handle these files might be the wrong way. Whonix VMs still need these.

stackable wrappers[edit]

check out bubblejail[edit]

sandbox-app-launcher[edit]

  • sandbox-app-launcher
  • review
  • promising? worth bringing back to life, polishing?
  • at odds with apparmor.d?
  • better using bubblejail?

automated test suite - cli version[edit]

  • todo: discuss

apparmor.d review[edit]

apt-get - implement --restrict-install-recommends proof of concept[edit]

  • todo

improved server support[edit]

  • documentation
    • rebrand wiki CLI for server
  • Linux account passwords?
  • cloudinit?
  • vm-config-dist versus autologin CLI vs GUI vs server

WAITING ON[edit]

grml-debootstrap - fix UEFI bootloader updates[edit]

  • https://github.com/grml/grml-debootstrap/issues/297archive.org
  • please send a pull request upstream
    • Pull request: https://github.com/grml/grml-debootstrap/pull/299archive.org
    • This is specific to how grml-debootstrap works, Kicksecure will need some extra code of its own to work properly here since we use a different bootloader ID than Debian does (ours is kicksecure, theirs is debian).
      • Patrick: Please make bootloader ID configurable in grml-debootstrap. (They'll probably accept that because grml is an independent Linux distribution, might have use for that too and are generally easy to work with.)
        • Aaron: Done.
      • Patrick: Please patch derivative-maker to make use of this new feature and set custom bootloader ID.
        • Aaron: Will wait to do this until the patch is merged upstream, unless things take long enough that we have a good reason to fork.
  • Patrick: please use, review the following simplification, if sane
    if [ -z "$VMEFI" ]; then
      grub_pc_package_name=grub-pc
    else
      # We install grub-pc-bin instead of grub-pc when EFI is enabled, because
      # otherwise the EFI bootloader won't be automatically updated when GRUB
      # packages are uploaded. Doing this means that the BIOS bootloader won't
      # be automatically updated, which stinks, however the BIOS bootloader
      # doesn't have the same security concerns as the EFI bootloader (there's
      # no Secure Boot to grapple with when using legacy BIOS boot) so it's
      # better to let the BIOS bootloader lag behind and update the EFI one
      # than to let the EFI bootloader lag behind and update the BIOS one.
      grub_pc_package_name=grub-pc-bin
    fi

    if ! clean_chroot "${MNTPOINT}" dpkg --list "$grub_pc_package_name" 2>/dev/null | grep -q '^ii' ; then
      echo "Notice: '$grub_pc_package_name' package not present yet, installing it therefore."
      # shellcheck disable=SC2086
      clean_chroot "$MNTPOINT" DEBIAN_FRONTEND=$DEBIAN_FRONTEND apt-get -y --no-install-recommends install $DPKG_OPTIONS "$grub_pc_package_name"
    fi
    • Integrated.
  • Patrick: Please consider using numbers and lowering priority. Since it's unlikely that any other configuration file changes EFI ID, specifically by the time grml-debootstrap runs, maximum priority is unnecessary. Always best to keep free space for hypothetical derivatives.
        echo "GRUB_DISTRIBUTOR='${EFI_ID}'" > "${MNTPOINT}"/etc/default/grub.d/z-grml-debootstrap-efi-id.cfg
    • Discussed, elected not to do this.
  • Run clean_chroot "$MNTPOINT" debconf-set-selections <<< 'grub-efi-amd64 grub2/force_efi_extra_removable boolean true' unconditionally in all cases? That would make it easier to add an option in case upstream does not wish to enable that by default.
    • Discussed, elected not to do this.
  • Avoid repetitive clean_chroot "$MNTPOINT" DEBIAN_FRONTEND=$DEBIAN_FRONTEND apt-get -y --no-install-recommends install $DPKG_OPTIONS command in source code, only set package name so the source code has this command only once to install the GRUB package? Not sure it is a good idea to mix this refactoring into this pull request. Might be better to do that later in a follow-up pull request once that one was merged.
    • Not done yet to avoid overcomplicating the PR.
  • ARM_EFI_TARGET: Assume that works similarly, use the new debconf-set-selections method?
    • Done, actually I just removed ARM_EFI_TARGET entirely.
  • CI testing: https://github.com/Kicksecure/grml-debootstrap/pull/1archive.org

trixie port - misc[edit]

trixie port - port to Wayland[edit]

trixie port - meta packages[edit]

calamares - make 3.3.12 available in Bookworm[edit]

  • necessary to fix bugs related to the disk encryption user interface
  • Sid and Trixie are still at 3.3.9, does maintainer need help packaging 3.3.12?
    • Maintainer uploaded 3.3.12 to Sid, should migrate to Testing relatively soon.
    • 3.3.11 was hung up on calamares-extensions 3.3.1, and while calamares-extensions 3.3.11 is technically available, a real release of it hasn't been made. Pinged the Calamares devs to see if they could do that, after than I'll ping the Debian Qt/KDE team to get them to package it and that should release calamares into Trixie.
    • 3.3.12 was uploaded but was slightly wonky, wasn't migrating, maintainer wasn't fixing the issue yet. Got a DD friend to sponsor an NMU to fix the problem, should hopefully migrate on December 22nd if all goes well. (Thanks to Simon Quigley for sponsorship!)
  • Backport 3.3.12 after it is available in Trixie
    • Backport submitted to Debian Mentors, review requested from maintainer.

ISO - GRUB - silence cosmetic errors in live ISO GRUB[edit]

  • Earlier attempts to fix cosmetic errors in GRUB failed, since they introduced bugs into the live-build-provided boot screen.
  • Investigate how to fix this, potentially make an upstream feature request or patch if needed
  • Errors include loadfont issues, Secure Boot loading issues
  • Sent email to grub-devel mailing list to investigate this

ISO - memtest86+[edit]

error: bad shim signature

test SysRq keys under LXQt Wayland[edit]

ISO - btrfs versus grub-live bug - real fix[edit]

  • todo
  • report bug upstream
  • systemd bug report: https://github.com/systemd/systemd/issues/35540archive.org
  • fix in dracut
    • Cannot be fixed in dracut, dracut doesn't handle mounting /home. Instead opting to fix in grub-live.
    • Might use kernel parameters using systemd features that may be available in trixie?

ISO - changed files issues[edit]

(annoted) 

+ debsums --silent
debsums: changed file /usr/sbin/sources-media (from calamares-settings-debian package) - issue for future verified boot
debsums: missing file /var/lib/dbus/machine-id (from dist-base-files package) - issue for Whonix-Host, non-ideal for Kicksecure but not a blocker

+ debsums --config --silent
debsums: changed file /etc/calamares/modules/unpackfs.conf (from calamares-settings-debian package) - issue for future verified boot
debsums: changed file /etc/cryptsetup-initramfs/conf-hook (from cryptsetup-initramfs package) - issue for future verified boot
debsums: changed file /etc/machine-id (from dist-base-files package) - issue for Whonix-Host, non-ideal for Kicksecure but not a blocker
  • All of these are modified by live-build itself:
    • /usr/sbin/sources-media is modified by live-build/share/hooks/normal/5050-dracut.hook.chroot so that it points to the proper location of the on-ISO apt repo when dracut is in use (the location is different when initramfs-tools is used). The need for this could potentially be removed by modifying the sources-media script to autodetect the correct location, though this requires upstream to be receptive to the idea.
    • /var/lib/dbus/machine-id is deleted by live-build/share/hooks/normal/8020-remove-dbus-machine-id.hook.chroot, which has a note in it as follows: "This removes dbus machine id that cache that makes each system unique." This seems important and I can't think of an obvious way to avoid needing to do this. My Kicksecure VMs appear to have machine IDs, but it's unclear how they're being generated originally, so it may be worth enabling the machineid module in our Calamares configuration to ensure that the machine ID is properly generated.
    • /etc/calamares/modules/unpackfs.conf is modified by live-build/share/hooks/normal/5050-dracut.hook.chroot so that it points to the proper location of the on-ISO squashfs containing the operating system. Again, the location is different when initramfs-tools is used. This is a "hardcoded" configuration file, there isn't a way to add autodetection logic here. It might be possible to make a pull request to Calamares that would allow it to skip squashfses that didn't exist?
    • /etc/cryptsetup-initramfs/conf-hook is modified by live-build/share/hooks/normal/1010-enable-cryptsetup.hook.chroot, where it is used to enable cryptsetup in initramfs-tools. Assuming this isn't legacy configuration, this seems important and I can't think of an obvious way to avoid needing to do this. Might be worth testing to see if this is still necessary though.
    • /etc/machine-id is deleted by live-build/share/hooks/normal/8020-remove-dbus-machine-id.hook.chroot. Has a very similar note to the other machine ID deletion hook. Same concerns apply.
      • Proposal for fixing this made.

ISO - Finish Module Action Follow-Up[edit]

lightdm ssdm[edit]

live-build - add mmdebstrap support[edit]

live-build - use APT with error-on-any[edit]

  • use option apt --error-on=any for all invocations of apt-get (update)
  • only needed for apt-get update, otherwise superfluous but non-issue
  • this is a security feature
  • this is to prevent inconsistent images that succeeded connecting to the "normal" repository but failed to connect to the security repository
  • can be implemented using already existing live-build option --apt-options OPTION|"OPTIONS"?
  • Requires a patch to live-build. Using --apt-options results in a build failure with E: Command line option --error-on=any is not understood in combination with the other options
  • Patch written, submitted upstream as https://salsa.debian.org/live-team/live-build/-/merge_requests/371archive.org. New configuration option now used in my branch of live-build.

security-misc - investigate PAM[edit]

live-build - local repository support[edit]

live-build - grub.cfg GRUB configuration - loopback.cfg[edit]

  • add https://www.supergrubdisk.org/wiki/Loopback.cfgarchive.org compatibility (as as Debian Live ISO)
  • Requires fixes in live-build and Dracut to make work:
    • live-build is specifying the wrong kernel parameter for loopback booting when using dracut - it's using findiso when it should be using iso-scan/filename. A fix for this has been integrated into my fork of live-build. MR to upstream here: https://salsa.debian.org/live-team/live-build/-/merge_requests/376archive.org
    • dracut is failing to run udevadm trigger during its device scanning, so even when it finds the ISO and attaches it as a loopback device, it never finds it. Only appears to be a problem on Debian Bookworm, Trixie works just fine.
      • Task is on hold until we migrate to Trixie.
    • (Side note: At least on QEMU, loopback mounts in GRUB fail with out-of-memory errors if the system uses UEFI. With BIOS it works fine. Not quite sure why this happens, very well may be an issue with QEMU's implementation of UEFI hardware or my usage thereof.)

live-build - lb-binary should not run apt-get update[edit]

REVIEW PLEASE[edit]

Kicksecure DNS proper /etc/resolv.conf during build process[edit]

user-sysmaint-split - shutdown action[edit]

permission-hardener - restore permissions on configuration changes[edit]

review list of remaining SUIDs[edit]

sudo find / -perm -4000 -type f -executable 

/usr/lib/qubes/qfile-unpacker
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/chromium/chrome-sandbox
/usr/lib/openssh/ssh-keysign
/usr/lib/polkit-1/polkit-agent-helper-1
/usr/sbin/pam-tmpdir-helper
/usr/bin/fusermount3
/usr/bin/sudo
/usr/bin/pkexec
/usr/bin/qfile-unpacker
  • /usr/lib/qubes/qfile-unpacker: Probably still needed.
    • Appears to be an integral part of file transfer between qubes, stripping SUID from this in an AppVM results in that AppVM being unable to receive files any longer. (It can still send files to other qubes though.)
  • /usr/lib/dbus-1.0/dbus-daemon-launch-helper
    • Needed for D-Bus system activation to work, see https://dbus.freedesktop.org/doc/system-activation.txtarchive.org. May be vital for desktop features to work normally. Appears to have been designed with security in mind and can only be called by root or a user in the messagebus group (which currently has one member, namely user messagebus).
  • /usr/lib/chromium/chrome-sandbox: Probably OK.
  • /usr/lib/openssh/ssh-keysign: ?
    • Used only for SSH host-based authentication (https://linux.die.net/man/8/ssh-keysignarchive.org), needed to allow access to the machine's host key for use in the authentication process. This is a non-default method of authenticating to SSH, and is likely rarely used, thus I believe this should be safe to disable.
  • /usr/lib/polkit-1/polkit-agent-helper-1: Should be handled in user-sysmaint-split?
  • /usr/sbin/pam-tmpdir-helper: ?
    • Used by the pam_tmpdir module to create a secure temporary directory for the user that is logging in. (https://manpages.ubuntu.com/manpages/oracular/man8/pam-tmpdir-helper.8.htmlarchive.org) Apparently specific to Debian, there isn't actually any Git repo with this code in it, it's just a "floating" package in the Debian archive. Written by the same person who maintains the package. Almost certainly cannot be disabled without causing serious problems, but may be worth auditing. (Worthy of note, it doesn't seem this program takes any user input, but relies solely on the calling user's UID and GID, though I could have missed something.)
  • /usr/bin/fusermount3: ?
    • Critical component of FUSE (Filesystem in USErspace), used by things such as AppImages and Docker. If not SUID, unprivileged users will be unable to use FUSE any longer - this completely breaks AppImages, among other things. Should be left enabled to avoid causing problems.
  • /usr/bin/sudo: Done. (Handled in user-sysmaint-split.)
  • /usr/bin/pkexec: Done. (Handled in user-sysmaint-split.)
  • /usr/bin/qfile-unpacker: Probably still needed.
    • Not bit-for-bit identical to /usr/lib/qubes/qfile-unpacker, and stripping SUID from this does *not* break file copying. Unsure what this is for, asked in Qubes OS Matrix room for clarification.

analyze pam stack[edit]

  • old:
/usr/bin/sudo /usr/bin/apt update
Sorry, try again.
Sorry, try again.
sudo: 3 incorrect password attempts
Command exited. You may close this window safely.
  • new:
[template  user ~]% sudo apt update      
Sorry, user user is not allowed to execute '/usr/bin/apt update' as root on localhost.
zsh: exit 1     sudo apt update
  • due to pam wheel changes, this works better now
  • todo: why does this work better now? the pam wheel changes should not affect that.
    • If you open /etc/pam.d/common-auth, you'll see the auth stack most things that use PAM (including sudo and su) use in Debian. Critically, sudo shares this stack with su.
    • pam_wheel checks the user calling it, to determine if that user is in a specific group. If not, access is denied. This doesn't block lightdm login because lightdm runs as root, and root is (apparently) allowed to authenticate as anyone. However, if user user is not in the specified group (in our case sudo), access is denied, regardless of what user user is trying to do.
    • Our old PAM stack ran pam_wheel for any successful authentication, which meant that anything the user tries to use that requires authentication (sudo, pkexec, su) will fail due to failed authentication. This applies even if user user is passwordless, in which case one will see authentication automatically fail without any other user input. sudo attempts authentication three times, so you get three failure messages.
    • Adjusting PAM to only run pam_wheel when running su fixes the issue because now su is the only thing that will attempt to use pam_wheel. Anything else will ignore it, and so authentication will succeed. In the case of sudo, it will then check, see that user user is not part of group sudo and return a clear error message, rather than an authentication failure message.

ARCHIVED[edit]

user-sysmaint-split - review changes[edit]

  • Patrick made some minor changes.
    • Reviewed, looks good to me. Will test when adding the sysmaint account lock shutdown action.

address Linux Installer review[edit]

DNS - Kicksecure Default DNS Discussion[edit]

document ARP related sysctl changes[edit]

permission-hardener - usrmerge[edit]

  • assume usrmerge, make it a dependency
  • simplify configuration (/bin no longer needed)
  • Distribution morphing: document, if applicable

user-sysmaint-split - rads integration[edit]

  • review Patrick's changes
  • avoid "systemctl start rads" hardcoded, if possible.
  • Reasons: Qubes does not come with rads by default. System might not have rads. User might have uninstalled rads. Difficult to check if a systemd unit is installed. (systemctl list-units | grep rads - might find a similar names systemd unit.)
  • Fixed, now starts rads using the systemd target instead: https://github.com/ArrayBolt3/user-sysmaint-split/tree/arraybolt3/avoid-rads-in-scriptarchive.org

permission-hardener refactor[edit]

  • Avoid lazy loading, instead build state arrays ancd apply them in an idempotent fashion
  • Currently planned algorithm:
    • Build the state first, starting with an empty state array if there is no state or loading an existing state array if there is state. For each file mentioned in the policy, check to see if it's in the state array, and if not, add its current user owner, group owner, and permissions state to the array. (TODO: How to handle capabilities? For now we can just support stripping them and not support adding them back.)
    • Next, apply the policy to the state. Copy the state array to a new array, and then change the user owner, group owner, permissions state, and capabilities to match the policy. It is important that it be done this way, because this means if the policy used to modify a file, but now no longer does, that file's original permissions state will exist in the state array, and thus will be considered part of the state that permissions-hardener applies.
    • Apply the built, policy-enhanced state to the filesystem's active state. For each file in the state array, delete the file's entry in dpkg-statoverride, then change the file's actual state to match the state array (again using dpkg-statoverride to do this)
    • To undo a policy for a file, load the state file, wipe the dpkg-statoverride entry for it, and then apply the stored state to the real file.
  • Ready for review: https://github.com/ArrayBolt3/security-misc/tree/arraybolt3/permission-hardener-refactorarchive.org
  • PR: https://github.com/Kicksecure/security-misc/pull/293archive.org

user-admin-split - installer sysmaint support[edit]

user-sysmaint-split - Wayland support[edit]

  • sddm support (because that is LXQt's default login manager)
    • Can set default user account and session by modifying /var/lib/sddm/state.conf
  • Needs to use labwc as window manager instead of xfwm4 when in Wayland mode
  • Might need separate sessions for Wayland and X11, provided either by different packages or with some configurable switch
    • Patrick: multiple packages best avoided as discussed
  • Implementation (SDDM tested, Wayland untested): https://github.com/ArrayBolt3/user-sysmaint-split/tree/arraybolt3/wayland-sddm-supportarchive.org
  • Will be difficult to fully test until Kicksecure's Trixie port is underway

calamares - investigate keyboard layout issue[edit]

report research results to purism[edit]

  • as discussed
  • Done.

pam wheel - review[edit]

  • please review Patrick's new pam wheel implementation
    • Reviewed and tested, looks good and works as intended on my end.

sysmaint-panel - Qubes support[edit]

  • bug: when qubes-core-agent-passwordless-root is not installed but user-sysmaint-split is not installed, sysmaint-panel fails to notify the user that root escalation is failing
/usr/bin/sudo /usr/bin/apt update
Sorry, try again.
Sorry, try again.
sudo: 3 incorrect password attempts
Command exited. You may close this window safely.
  • issue introduced by Kicksecure. not applicable with Qubes qvm-template install debian-12-minimal
  • Issue caused by security-misc/usr/share/pam-configs/wheel-security-misc. If user user is not in group sudo, this check fails and causes PAM authentication to fail, even if user has no password.
    • This file seems obsolete - the file states that it prevents users who aren't part of group wheel from using su, but su isn't even executable by anyone other than root due to permission hardening.
    • Issue should be resolvable by adding user to sudo in the template, or by removing this config file.
    • After discussion with Patrick, preferred solution is to create a script that can detect if the `su` command is being called, and only ensure that the user account in use is in the `sudo` group if this is the case.
    • After further research, su actually has a PAM configuration file that can be used here, allowing us to use pam_wheel as intended without causing conflicts.
  • Fix: https://github.com/ArrayBolt3/security-misc/tree/arraybolt3/fix-sudoarchive.org
    • Patrick: not merged. implemented with a different implementation. follow-up ticket created.

ISO - ARM64 build failing[edit]

./derivative-maker --target iso --flavor kicksecure-xfce --repo true --remote-derivative-packages true --arch arm64

Setting up python3-pil:arm64 (9.4.0-1.1+deb12u1) ...
Traceback (most recent call last):
  File "/usr/bin/py3compile", line 323, in <module>
    main()
  File "/usr/bin/py3compile", line 302, in main
    compile(files, versions,
  File "/usr/bin/py3compile", line 187, in compile
    cfn = interpreter.cache_file(fn, version)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/share/python3/debpython/interpreter.py", line 212, in cache_file
    (fname[:-3], self.magic_tag(version), last_char))
                 ^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/share/python3/debpython/interpreter.py", line 246, in magic_tag
    return self._execute('import imp; print(imp.get_tag())', version)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/share/python3/debpython/interpreter.py", line 359, in _execute
    raise Exception('{} failed with status code {}'.format(command, output['returncode']))
Exception: ('python3.11', '-c', 'import imp; print(imp.get_tag())') failed with status code -11
dpkg: error processing package python3-pil:arm64 (--configure):
 installed python3-pil:arm64 package post-installation script subprocess returned error exit status 1
  • This appears to be a bug in either Xen or QEMU. python3 intermittently segfaults when run in an arm64 chroot emulated on an amd64 machine. To reproduce simply, boot into Qubes OS, open a Debian 12 AppVM, ensure qemu-user-static and mmdebstrap are installed in the AppVM, then run sudo mmdebstrap --architecture=arm64 bookworm armtest. Then bind-mount important dirs with sudo mount --bind /dev armtest/dev && sudo mount --bind /dev/pts armtest/dev/pts && sudo mount --bind /proc armtest/proc && sudo mount --bint /sys armtest/sys. Then chroot in, run apt update && apt install python3, and then finally run the following segfault reproducer:
for i in {1..800}; do
   python3 -c 'import imp; print(imp.get_magic())' >/dev/null 2>/dev/null
   exit_code="$?"
   echo "$exit_code"
   if [ "$exit_code" != '0' ]; then
      break
   fi
done
  • This should output a lot of zeros, but eventually it should segfault and return non-zero. This usually happens at least once in 400 runs for me, but it's possible that it won't happen that soon, thus why the above reproducer tries 800 times.
  • This issue only occurs under Qubes OS for me. In a KVM VM, even 1600 attempts does not segfault on my machine.
  • The version of QEMU in bookworm-backports appears to have solved this. Run sudo apt install -t bookworm-backports qemu-user-static in your Debian 12 (or Kicksecure) template, shut down the template and reboot affected AppVMs, then attempt the above reproduction steps again. It should not segfault even with 1600 attempts. I have also confirmed that an ISO build succeeds when doing this.
  • Worth reporting to Debian as a bug report against Bookworm specifically? (This probably doesn't affect Sid since it's using a newer QEMU version, approximately the same version as in bookworm-backports.)
  • Worth enhancing the derivative-maker dependency installation code to allow specifying specific packages from backports so that we can ensure that qemu-user-static from bookworm-backports is used?

iso - calamares - Argon2id[edit]

heads ticket[edit]

user-sysmaint-split - ISO - sysmaint mode - #3[edit]

research verified boot and measured boot[edit]

Update #1:

Please review:

Considered:

How does android implement relock bootloader with user custom keys?

  • Document shortcomings with a vendor-provided, no-true-ROM solution
    • There may not be serious shortcomings with this after all.
  • Android trusts the hardcoded android hardcoded bootloader?
    • The firmware does appear to be implicitly trusted. It is possible that the device SoC cryptographically verifies the firmware similar to Boot Guard, but if so, this isn't documented anywhere obvious, and it doesn't appear that Android Verified Boot considers malicious system firwmare in the threat model.
  • https://android.stackexchange.com/questions/238980/why-is-it-possible-to-re-lock-the-bootloader-after-installing-a-custom-rom-on-sarchive.org
  • Android: User-settable root of trustarchive.org
  • Android: Boot Flowarchive.org
  • Android: Figure 1. Verified boot flow.archive.org
  • rollback protection
  • theft protection
  • factory reset protection
  • watch some videos on how Android is flashed, locked, unlocked, relocked
  • Figure out how Heads avoids relay attacks with firmware verification, if it does -> https://github.com/linuxboot/heads/issues/1881archive.org
  • android hardware keystore (HSM)
    • This is of questionable use for verified boot. It might be useful for factory reset protection but there may be better ways to do that. It also relies on an ARM TrustZone "secure world" which is scary.
  • See if adding some sort of secure, append-only storage is useful and work it in if so (hardware keystore hsm)
    • Most likely is useful for rollback protection, documented. It could be implemented using a "secure world" similar to TrustZone but it seems better to implement it in hardware, potentially.
  • TPM MITM issue
    • This is only really a problem if the attacker can modify the motherboard, which is a threat model that is extremely difficult to defend against and should probably be considered out-of-scope.
  • offline theft protection
  • online theft protection (remote locking)
    • Likely too difficult. Requires a cloud service in the middle, which is bad for privacy and a potential security hole itself.
  • compare TOTP vs challenge response based (NitroKey). Or "nothing" (Android)?
    • TOTP and HOTP are both potentially vulnerable to relay attacks, HOTP less so if used carefully. Better yet still would be a data signature challenge (i.e. here's a blob of random data, sign it and send it back to me so I can check that your signature is good).
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
6e:45:f9:a8:af:38:3d:a1:a5:c7:76:1d:02:f8:77:00.
Please contact your system administrator.
Add correct host key in /home/hostname /.ssh/known_hosts to get rid of this message.
Offending RSA key in /var/lib/sss/pubconf/known_hosts:4
RSA host key for pong has changed and you have requested strict checking.
Host key verification failed.
  • either send own hardware or TOFU
    • Send own hardware is highly preferable
  • maybe solvable if cloud vendor reveals TPM EK fingerprint beforehand?
    • Not sufficient. The TPM can be fooled by firmware if Boot Guard isn't in use, and the user can't be sure that Boot Guard is in use unless they can either remotely verify the authenticity of the CPU (likely not possible unless using Intel TDX or AMD SEV) or they can verify it locally.
  • explain how others do it, compare: With Android, where companies are protecting themselves from the user, the same thing is true. The "owner" (manufacturer) can provision the system the way they want and the "attacker" (user) can't do anything about it (Device Attestation such as SafetyNet)
  • remote attestation is possible without verified boot? if known, please document, if unknown answer, please mention.
    • Yes, it is possible, see https://safeboot.dev/attestation/archive.org. It appears that TPM measurements are used by the machine being attested to prove its identity to the machine doing the attesting.
  • custom kernel modules? re-invent MOK?
    • If we're using UEFI Secure Boot like our current plan states, we can just use the MOK mechanism as-is. We also could have the user sign their kernel modules so they pass Secure Boot normally.
  • boot guard -> dasharo (3MDEB) firmware -> heads (?) -> verify Debian's kernel against Debian's key?
    • No need for Heads, we're just using UEFI.
  • maybe the unchangeable root of trust would be well placed with boot guard, dasharo. the hopefully socially incorruptible organisation becoming the caretaker of taking care the most difficult parts.
    • Easier to have no single root of trust, instead have toggleable roots of trust for each distro and also allow the user to set their own root of trust.
  • key management could be done at a "simpler level". at the level of heads (or similar).
    • Some sort of key management tooling will be needed, and since we're using UEFI directly this may be difficult. Perhaps a UEFI application can be made that will make this easier? Or do we just need special firmware features? (We may need some way for the user to change Secure Boot keys remotely for the purposes of credential rotation, although this might not be needed and could be scary.

Concept improvements:

  • stage 0 - super simple, write firmware from USB, no display graphical output support, truly read-only
  • stage 1 - dasharo default firmware
  • stage 2
  • Verify distribution (Debian) kernel against distribution public key. Making use of EFI signatures but without using EFI.
  • Mention why not using EFI.
  • What if evil maid flashes using stage 0? -> Should break TOTP or similar mechanism.
  • stage 1 preinstalled dasharo/heads firmware is required to match usability of user-settable root of trust, re-lock bootloader with user key supported Android phones such as Google Pixel.
  • OS rollback protection
  • factory reset protection
  • Firmware rollback protection? if the user changes firmware keys on every update that might give us this "for free", but the key changes could be an expensive operation
  • Document the need for a true ROM for firmware installation in the current design
  • Create alternate design that involves no true ROM and vendor-provided firmware
  • Review Google's Android docs more and pull in anything that would make either design better
  • usability: at least as good as Android phones, if not better
  • no concept of OEM ROMs -> user chosen operating systems are the primary focus
  • compatibility with standard Linux distributions, if possible
  • windows compatibility? Probably not, unless there's an alternative enable EFI option in the firmware
  • android: users can their own key but they can also use images by distributions
  • replay attacks
  • relay attacks

user-sysmaint-split - remove advanced boot options for first time start[edit]

iso sysmaint mode - #2[edit]

review wiki - shadow and ssh[edit]

sysmaint - no autologin if password is set - #2[edit]

  • If there's a password set, do not auto login. Prompt for password using normal login or display manager mechanism instead.
  • users always need an opt-in way to set passwords, disable autologin.
  • Done: https://github.com/ArrayBolt3/user-sysmaint-splitarchive.org
  • Patrick: bug found
    • /usr/libexec/user-sysmaint-split/sysmaint-boot. currently we're checking twice kernel boot parameter. i think the logic can be simplified.
      • if in non-sysmaint (user) boot mode -> lock sysmaint and safe-rm any autologin config files that might exist
    • bug: and let's say "/usr/sbin/lightdm" does exist. but we're not in sysmaint mode. currently what happens: do not delete the lightdm configuration file.
    • Both issues fixed: https://github.com/ArrayBolt3/user-sysmaint-splitarchive.org

live-config-dist- check-unrestricted-admin TMP folder[edit]

  • /usr/libexec/live-config-dist/check-unrestricted-admin
export TMPDIR='/tmp'
  • necessary? needs to be commented or removed
  • Fixed dummy-dependency and removed this from check-unrestricted-admin.

calamares - implement - Allow distros to restrict what filesystems can be used in manual partitioning[edit]

fix Secure Boot fallback bootloader problems[edit]

ISO - Debug chsh failure[edit]

/var/lib/dpkg/info/dist-base-files.postinst: INFO: Setting shell for user 'user' to zsh.
Password:
chsh: PAM: Authentication failure
/var/lib/dpkg/info/dist-base-files.postinst: ERROR: Command 'chsh --shell /usr/bin/zsh user' failed. This is only a minor issue.

ISO - use BUILD_INITRAMFS_PKGS[edit]

boot modes wiki page review[edit]

  • Dev/user-sysmaint-split has been updated
  • Please review.
  • Ideas for chapter Server Support, and
  • chapter Todo?
  • Related to upcoming tasks run0, sudoless, doas.
  • I do not believe we should be implementing opt-out by having the user uninstall or delete things. Instead, let's provide a "Classic" option that the user can select at the boot menu, and provide guidance on modifying the default boot option.
    • Patrick: The "classic" option would be confusing in the boot menu. Better to make user-sysmaint-split package uninstallable: dummy-dependency user-sysmaint-split
      • Aaron: Sounds good.
        • Patrick: Wiki page updated.
  • Do we really want a recovery mode admin option? We specifically wanted to get rid of easy recovery mode access elsewhere.
    • Patrick: Wiki was outdated on that. Recovery mode can stay disabled. Wiki has been updated to remove recovery mode.
  • Server support can be handled by changing the default boot entry using grub-set-default most likely.
    • Patrick: This would mean to boot the server always into admin mode? In that case, perhaps better to go back to "classic"?
      • Aaron: Yes, and that's included in the dummy-dependency user-sysmaint-split plan, so that's what we can do. Perhaps kicksecure-host-cli should use "classic" mode by default and kicksecure-host-xfce should use "user-sysmaint-split" by default?
        • Patrick: Yes. Wiki page updated.
  • We need to choose what the default, topmost boot entry will become. Should that be "PERSISTENT mode User"?
    • Patrick: Yes.
  • We may want to prepend "Kicksecure" to all of these boot menu entries for clarity as to which operating system is which. For Whonix, we can prepend "Whonix" to the boot menu entries.
    • Patrick: Yes.
  • Added some more ideas, including thoughts for server support. I don't think we need a todo chapter since this dev/todo document works as that.

review USBGuard pull request[edit]

review ARP related network settings[edit]

document sysmaint warnings in wiki[edit]

  • as discussed
  • sysmaint
  • Documented. Didn't add a screenshot of the warnings from LightDM though since I didn't think they were worth the space on the page, I can add them if desirable.

user-sysmaint-split and sysmaint-panel improvements[edit]

  • rationale:
    • A single command dummy-dependency --yes --purge user-sysmaint-split would be sufficient to go back to classic sudo setup. Uninstallation of sysmaint-panel would be unnecessary. Users could use sysmaint-panel even in classic sudo setup.
    • sysmaint-panel should be fully independent from user-sysmaint-split. It could also be used in classic sudo mode, where user "user" has access to sudo/pkexec.
    • easier to test sysmaint-panel
    • Qubes compatible
   subprocess.Popen(["/usr/libexec/helper-scripts/terminal-wrapper",
                         "/bin/sh", "-c", "$SHELL"])

echo "[Desktop]
Session=sysmaint-session" \
   | sponge -- '/home/sysmaint/.dmrc'
  • needs to be run under user sysmaint to avoid permission issues
  • needs Depends: safe-rm maybe?
  • sysmaint-panel folder /usr/lib/systemd/system doesn’t seem right for a gui package. Maybe...
    • user-sysmaint-split-cli
    • user-sysmaint-split-gui
    • sysmaint-panel
      • would be a good split?
      • But actually we can get that down to 2 packages only. user-sysmaint-split + sysmaint-panel
  • move https://github.com/Kicksecure/sysmaint-panel/blob/master/usr/libexec/sysmaint-panel/sysmaint-sessionarchive.org
    • to user-sysmaint-split
    • How? By making sysmaint-panel a "plugin" or "extension".
xfwm4 &
# Needed to prevent window ordering problems
sleep 1;
sysmaint-panel
  • could be changed to: if available, run sysmaint-panel. otherwise, just open a terminal. Pseudo code, untested:
xfwm4 &
# Needed to prevent window ordering problems
sleep 1;
## NOTE: bashism
if command -v sysmaint-panel &>/dev/null ; then
  sysmaint-panel
else
  /usr/libexec/helper-scripts/terminal-wrapper "$SHELL"
fi

investigate dracut-config-generic[edit]

  • VM images use dracut-config-generic because help-steps/variables has:
[ -n "$BUILD_INITRAMFS_DRACUT" ] || BUILD_INITRAMFS_DRACUT="dracut dracut-live dracut-config-generic binutils dmsetup pigz"
  • ISO images do not have dracut-config-generic
apt-file list dracut-config-generic 
dracut-config-generic: /etc/dracut.conf.d/20-generic-image.conf
cat /etc/dracut.conf.d/20-generic-image.conf
hostonly="no"
  • TODO: Would it be useful to have this package also on the ISO? Specifically since it would be useful if this package ends up on the installed system to always have a generic initial ramdisk as well as for feature/bug parity with VM images.
  • Patrick: Seems actually already done as per:
live-build/scripts/build/config:                        NEEDED_PACKAGES="live-config live-config-systemd systemd-sysv dracut-live dracut-config-generic dracut"
  • Aaron: Confirmed, chrooting into the squashfs on a live-build-built Kicksecure ISO and running dpkg-query -s dracut-config-generic shows that it is install ok installed. Furthermore the 20-generic-image.conf file exists on the ISO.

investigate sudoless[edit]

user-sysmaint-split[edit]

pam-info improvements for user-sysmaint-split[edit]

admin-gui[edit]

VirtualBox unattended installation pass-through[edit]

  • how does that mechanism work?
  • Short, highly simplified answer: for Debian, it finds a file on the ISO at /.disk/info and parses it for info. This file identifies Kicksecure ISOs as being Debian, and it's difficult to customize the contents in live-build. Needs either customization options added or downstream patches.
  • Might be worth asking the VirtualBox people if they would consider adding a feature that would allow ISOs to "opt out" of autoinstall support, so that the user can't even try to use it in autoinstall mode.

investigate dracut-config-rescue[edit]

cat /etc/dracut.conf.d/20-rescue.conf
dracut_rescue_image="yes"
  • related to https://forums.kicksecure.com/t/harden-dracut-initramfs-generator-by-disabling-recovery-console/724archive.org?
  • TODO: good to keep or should be omitted?
  • There appears to be no differences between an initramfs built with dracut-config-rescue installed and one without it. According to the Arch Wiki (https://wiki.archlinux.org/title/Dracutarchive.org), the "rescue" module is supposed to provide tools such as vi, ping, etc., which are useful in the rescue shell, but I know from experience those are NOT present in Kicksecure's initramfs images. Thus I don't think it makes any difference either way. We could remove it in order to lighten our images, I don't expect this will cause any harm.
  • Diff output between initramfs generated with dracut-config-rescue present (old-unpack), and initramfs generated without it (newer-unpack):
root@localhost:~# diff -r -u old-unpack/ newer-unpack/
File old-unpack/main/dev/console is a character special file while file newer-unpack/main/dev/console is a character special file
File old-unpack/main/dev/kmsg is a character special file while file newer-unpack/main/dev/kmsg is a character special file
File old-unpack/main/dev/null is a character special file while file newer-unpack/main/dev/null is a character special file
File old-unpack/main/dev/random is a character special file while file newer-unpack/main/dev/random is a character special file
File old-unpack/main/dev/urandom is a character special file while file newer-unpack/main/dev/urandom is a character special file
diff: old-unpack/main/etc/systemd/system/initrd.target.wants/dracut-cmdline-ask.service: No such file or directory
diff: newer-unpack/main/etc/systemd/system/initrd.target.wants/dracut-cmdline-ask.service: No such file or directory
diff: old-unpack/main/var/lock: No such file or directory
diff: newer-unpack/main/var/lock: No such file or directory

dummy-dependency purge feature[edit]

    dummy-dependency [remove|purge] pkgname

dracut rescue shell disablement maybe broken - VirtualBox install unattended option result in dracut rescue shell[edit]

simple integrity check boot option[edit]

ISO - GRUB - failing to boot after installation[edit]

ISO - GRUB - cosmetic GRUB error message[edit]

  • environment: VirtualBox + EFI + Secure Boot (might be reproducible elsewhere too)
error: prohibited by secure boot policy
  • Turns out you can't load unsigned fonts when Secure Boot is enabled. It's possible that even the default unicode.pf2 font in GRUB is unsigned.
  • Can't find an easy way to detect Secure Boot so that we can avoid running commands that will result in errors.
  • There probably isn't an easy way to fix this, combining this into the "silence cosmetic errors" task.

recovery mode disabling[edit]

ISO - GRUB boot menu - add timeout to live boot menu[edit]

ISO - GRUB boot menu - utilities option does nothing[edit]

ISO - GRUB boot options text - add version number[edit]

Kicksecure Live ISO 17.2.8.1 GNU/Linux

${dist_build_type_short_pretty} Live ISO ${dist_build_version} GNU/Linux

ISO - GRUB boot menu cosmetic efi related error messages[edit]

  • tested where: inside Qubes OS VM
  • difficult to see unless recorded on video
error: file `/boot/grub/i386-pc/efi_gop.mod' not found.
error: file `/boot/grub/i386-pc/efi_uga.mod' not found.
  • Debian bug for the core image? Got some search results:
site:debian.org error: file `/boot/grub/i386-pc/efi_gop.mod' not found.
  • Maybe live-build fails to install a grub package?
  • Side effect of no longer installing Debian-Installer?
    • This is the result of fixing the missing font bug. If the unicode.pf2 font can be loaded, GRUB sets a static display resolution of 800x600 and attempts to load four different video drivers, two of which are the efi_gop.mod and efi_uga.mod drivers, and the other two of which are video_bochs and video_cirrus. If the font load fails, it allows the resolution to be automatically detected, and loads a driver called all_video. We're now ending up with the codepath involving the efi_gop and efi_uga drivers always hit since the font is now always found.
    • Coincidentally, I noticed a bug where VMs with virtio graphics would not get a fancy graphical prompt, presumably because virtio is handled by the all_video driver and not the other four drivers.
    • I think it would be best to just unconditionally use the all_video driver and autodetect resolution. The existing logic doesn't make sense to me, and because the font didn't even exist in the expected spot previously, we'd just be going back to the codepath we were hitting previously.
    • After experimentation, this didn't work well at all. Went back to old GRUB config code from upstream with a note that it does not work. Fixing this will require more study to see how to get GRUB to not show cosmetic errors like this.

ISO - btrfs versus grub-live bug - hotfix[edit]

  • bug: btrfs is persistent in grub-live mode, while it should not be
  • hotfix: please disable btrfs
  • Hotfixed and merged into Kicksecure.

derivative-maker git tag following[edit]

  • to empower reviewers to follow changes from one tag to another
  • as discussed
  • TODO: a generic script to reviews any (nested) git submodules going from one tag (or commit) to another
    • This turned out to be nearly impossible and definitely impractical.
  • TODO: document this on Dev/git
  • Discovered git diff --submodule=diff, which is useful
  • Created sample script that provides difftool-like features with meld, and shared it with Patrick.
  • Sent feature request / offer to contribute for git difftool --submodule=diff support in Git: https://lore.kernel.org/git/20241208030222.60e7ac70@kf-ir16/T/#uarchive.org
  • Found PatchViewer tool and documented use under Dev/git

investigate run0[edit]

grub-live debian control best practices[edit]

  • please review, improve
  • https://github.com/Kicksecure/grub-live/blob/master/debian/controlarchive.org
  • Should grub-live Depends: grub-live-dracut | grub-live-initramfs-tools?
    • The existing setup seems fine to me. It is unfortunate that Debian lacks the ability to specify a group of packages in a dependency declaration, as the existing structure seems like an awful lot of work to depend on either dracut, or live-boot + live-tools. But, it works, and it seems to me like the best way to do this given Debian's limitations and structure.

ISO - fwupd[edit]

ISO - GRUB unicode.pf2 error message[edit]

error: `/grub2/fonts/unicode.pf2' not found
  • Please fix.
  • Should be fixed in latest derivative-maker improvements.

ISO - live-build - misc improvements[edit]

advice on safe_echo vs dist-installer-cli[edit]

live-build downloads[edit]

  • investigate
  • Handled.

review source code - str_replace file garbage bug - str_match[edit]

swap-file-creator improvements[edit]

ISO - consider installing by default on ISO[edit]

      packages_to_be_installed+=" mokutil "
      packages_to_be_installed+=" keyutils "
      packages_to_be_installed+=" efibootmgr "
  • mokutil is already installed.
  • How about the others?
  • Note: architecture specific. AMD64 vs PPC etc.
  • These packages don't really cause any harm if installed on a BIOS machine, and both amd64 and arm64 UEFI machines may benefit from them. I don't see any reason why not to include them by default.
  • All of these are being installed by default on both amd64 and arm64 builds, and appear to be pulled in either by Calamares or by GRUB. I think we should leave these up to live-build to choose whether to automatically install them or not, since if we end up supporting platforms that use firmware other than BIOS or UEFI in the future, these might not be relevant.

multi architecture support[edit]

  • the following code can be removed from build-steps.d/1200_prepare-build-machine?
  • required by grml-debootstrap for arm64 builds?
  • please add support for other architectures to build-steps.d/2800_create-lb-iso
  • just only mostly generic code. theoretical support only. no actual builds test needed for all architectures at this time.
      ## The following grub packages are (partially) build dependencies by Debian live-build.
      ## Certainly required for amd64 ISO images booted with shim and grub.
      if [ "${host_architecture}" = "amd64" ]; then
         ## These packages are all available for the amd64 platform.
         ## "grub-mkrescue will automatically include every platform it finds." [1]
         ## [1] https://lists.gnu.org/archive/html/grub-devel/2014-03/msg00009.html
         ## Install them all for best compatibility and reproducible builds.
         ## Some might be unnecessary and waste a bit space.
         ## Maybe this can be optimized later.
         packages_to_be_installed+=" grub-efi-amd64-bin grub-pc-bin grub-coreboot-bin grub-efi-ia32-bin grub-xen-bin grub-ieee1275-bin "
         packages_to_be_installed+=" grub-efi-amd64-signed "
         packages_to_be_installed+=" shim-unsigned shim-signed shim-signed-common "
         packages_to_be_installed+=" shim-helpers-amd64-signed "
      elif [ "${host_architecture}" = "i386" ]; then
         packages_to_be_installed+=" grub-efi-amd64-bin grub-pc-bin grub-coreboot-bin grub-efi-ia32-bin grub-xen-bin grub-ieee1275-bin "
         packages_to_be_installed+=" grub-efi-ia32-signed "
         packages_to_be_installed+=" shim-unsigned shim-signed shim-signed-common "
         packages_to_be_installed+=" shim-helpers-i386-signed "
      elif [ "${host_architecture}" = "ppc64el" ]; then
         packages_to_be_installed+=" grub-ieee1275-bin  "
      elif [ "${host_architecture}" = "ppc64" ]; then
         packages_to_be_installed+=" grub-ieee1275-bin  "
      elif [ "${host_architecture}" = "sparc64" ]; then
         packages_to_be_installed+=" grub-ieee1275-bin  "
      elif [ "${host_architecture}" = "arm64" ]; then
         packages_to_be_installed+=" grub-efi-arm64-bin "
         packages_to_be_installed+=" shim-unsigned shim-signed shim-signed-common "
      elif [ "${host_architecture}" = "riscv64" ]; then
         packages_to_be_installed+=" grub-efi-riscv64-bin  "
      else
         true "${red}${bold}WARNING:${reset} ${under}The ISO to be build might be unbootable!${eunder}
- This is because bootloader support is not implemented when building on this
  systems's host_architecture.
- Either the build script does not know how to install the required grub '-bin'
  package for this architecture or the package is simply unavailable.
- Therefore ISO cross builds are unsupported. Patches welcome.
  Might be possible to implement this by running image-to-iso using qemu.
- There is also a small chance that host_architecture detection failed. (Using multiarch, wine?)"
      fi

older[edit]

Dev/todo/archived

backlog - one day[edit]

Qubes doas ticket[edit]

Qubes umask ticket[edit]

investigate porting from sudo to doas[edit]

doas - send pull requests to Qubes[edit]

  • Qubes doas ticket might be unlikely to get rejected. But replies could take a while.
  • Please send a pull requests. Since it is only 2 packages, 3 files the wasted effort if this gets rejected might be low enough?
qubes-core-agent: /etc/sudoers.d/qt_x11_no_mitshm
qubes-core-agent: /etc/sudoers.d/umask

qubes-input-proxy-sender: /etc/sudoers.d/qubes-input-trigger
  • Superceded by sudoless mode, moved to backlog

create /usr/local/etc/doas.d /etc/doas.d parser and /etc/doas.conf configuration file creator[edit]

  • parse /usr/local/etc/doas.d
  • parse /etc/doas.d
  • parse only configuration files ending with .conf
  • do not overwrite a file that does not contain our auto generated configuration file (could be user custom file)
    • echo a warning in that case
  • atomic, create variable then use sponge
  • add to security-misc
  • add a dpkg trigger
  • /etc/doas.conf would require a header pointing out it is auto-generated.
## Do not edit this file!
## Please create and add modifications to the following file instead:
## /usr/local/etc/torrc.d/50_user.conf

## This file was auto generated by '$BASH_SOURCE' at APT package installation time (a dpkg trigger).
  • Superceded by sudoless mode, moved to backlog

doas - add to security-misc permission hardener whitelist[edit]

  • todo
  • Superceded by sudoless mode, moved to backlog

doas - create /etc/doas.d configuration snippets[edit]

bootloader password[edit]

vm-config-dist re-installs same version[edit]

[user ~]% dpkg -l | grep vm-config
ii  vm-config-dist                                3:10.5-1                        all          usability enhancements inside virtual machines
[user ~]% upgrade-nonroot 
Get:1 tor+https://deb.debian.org/debian bookworm InRelease [151 kB]                                                                                                          
Get:2 tor+https://fasttrack.debian.net/debian bookworm-fasttrack InRelease [12.9 kB]                         
Get:3 tor+https://fasttrack.debian.net/debian bookworm-fasttrack/main amd64 Packages [5296 B]                            
Get:4 tor+https://deb.debian.org/debian bookworm-updates InRelease [55.4 kB]                                     
Get:5 tor+https://fasttrack.debian.net/debian bookworm-fasttrack/non-free amd64 Packages [492 B]                                          
Get:6 tor+https://deb.debian.org/debian-security bookworm-security InRelease [48.0 kB]     
Get:7 tor+https://fasttrack.debian.net/debian bookworm-fasttrack/contrib amd64 Packages [7332 B]
Get:8 tor+https://deb.kicksecure.com bookworm InRelease [62.0 kB]                    
Get:9 tor+https://deb.debian.org/debian bookworm-backports InRelease [59.0 kB]
Get:10 tor+https://deb.kicksecure.com bookworm/non-free amd64 Packages [913 B]
Get:11 tor+https://deb.debian.org/debian bookworm/non-free amd64 Packages [97.3 kB]
Get:12 tor+https://deb.debian.org/debian bookworm/non-free-firmware amd64 Packages [6236 B]
Get:13 tor+https://deb.debian.org/debian bookworm/contrib amd64 Packages [54.1 kB]
Get:14 tor+https://deb.debian.org/debian bookworm/main amd64 Packages [8789 kB]    
Get:15 tor+https://deb.kicksecure.com bookworm/main amd64 Packages [33.7 kB]      
Get:16 tor+https://deb.kicksecure.com bookworm/contrib amd64 Packages [509 B]
Get:17 tor+https://deb.debian.org/debian bookworm-updates/non-free-firmware amd64 Packages [616 B]                                                                                           
Get:18 tor+https://deb.debian.org/debian bookworm-updates/main amd64 Packages [2712 B]                                                                                                       
Get:19 tor+https://deb.debian.org/debian bookworm-updates/non-free amd64 Packages [12.8 kB]                                                                                                  
Get:20 tor+https://deb.debian.org/debian bookworm-updates/contrib amd64 Packages [768 B]                                                                                                     
Get:21 tor+https://deb.debian.org/debian-security bookworm-security/contrib amd64 Packages [644 B]                                                                                           
Get:22 tor+https://deb.debian.org/debian-security bookworm-security/non-free-firmware amd64 Packages [688 B]                                                                                 
Get:23 tor+https://deb.debian.org/debian-security bookworm-security/main amd64 Packages [206 kB]                                                                                             
Get:24 tor+https://deb.debian.org/debian bookworm-backports/main amd64 Packages [264 kB]                                                                                                     
Get:25 tor+https://deb.debian.org/debian bookworm-backports/contrib amd64 Packages [5624 B]                                                                                                  
Get:26 tor+https://deb.debian.org/debian bookworm-backports/non-free-firmware amd64 Packages [3852 B]                                                                                        
Get:27 tor+https://deb.debian.org/debian bookworm-backports/non-free amd64 Packages [11.1 kB]                                                                                                
Fetched 9891 kB in 8s (1227 kB/s)                                                                                                                                                            
Reading package lists... Done
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  vm-config-dist
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 40.2 kB of archives.
After this operation, 2048 B of additional disk space will be used.
Do you want to continue? [Y/n] ^Czsh: exit 130   upgrade-nonroot

[user ~]% apt-cache show vm-config-dist 
Package: vm-config-dist
Version: 3:10.5-1
Architecture: all
Maintainer: Patrick Schleizer <adrelanos@kicksecure.com>
Installed-Size: 135
Depends: sudo, adduser, p7zip-full
Replaces: power-savings-disable-in-vms, shared-folder-help
Homepage: https://github.com/Kicksecure/vm-config-dist
Priority: optional
Section: misc
Filename: pool/main/v/vm-config-dist/vm-config-dist_10.5-1_all.deb
Size: 40244
SHA256: 41fc4cd7e2f97bdcf23ff80b91cbbc339aca3c60445ffaa4725147e4e28d048a
SHA1: d150305c67a4d3949c714c4b16a6a2c1ebe63353
MD5sum: 471286ecd49b36d287b50f807685036b
Description: usability enhancements inside virtual machines
 Sets environment variable `QMLSCENE_DEVICE=softwarecontext` as workaround for
 "Automatic fallback to softwarecontext renderer".
 .
 It is not useful to open a screensaver or to power down the desktop for
 operating systems that are run inside VMs. There is no real display that could
 be saved and no real power that could be saved. From usability perspective it
 also is counter intuitive when looking at the VM window and only seeing a
 black screen. Therefore it makes sense to disable power savings in VMs.
 `/etc/X11/Xsession.d/20_kde_screen_locker_disable_in_vms.sh`
 `/etc/profile.d/20_power_savings_disable_in_vms.sh`
 `/etc/X11/Xsession.d/20_software_rendering_in_vms.sh`
 `/usr/share/kde-power-savings-disable-in-vms/kdedrc`
 `/usr/share/kde-screen-locker-disable-in-vms/kscreenlockerrc`
 .
 Disables screen locker when running in VMs because that is not useful either.
 .
 Makes setting up a shared folder for virtual machines a bit easier.
 .
  * Creates a folder `/mnt/shared` with `chmod 777`, adds a group
 "vboxsf", adds user "user" to group "vboxsf". Facilitates auto-mounting of
 shared folders.
 .
  * Helps using shared folders with VirtualBox and KVM a bit
 easier (as in requiring fewer manual steps from the user).
 .
  * `/lib/systemd/system/mnt-shared-vbox.service`
  * `/lib/systemd/system/mnt-shared-kvm.service`
 .
 Set screen resolution 1920x1080 by default for VM in VirtualBox and KVM.
 Workaround for low screen resolution 1024x768 at first boot. When using lower
 screen resolutions, Xfce will automatically scale down.
 `/etc/skel/.config/xfce4/xfconf/xfce-perchannel-xml/displays.xml`
 .
 Installs VirtualBox guest additions if package
 `virtualbox-guest-additions-iso` is installed if environment variable
 `dist_build_virtualbox=true` or if running inside VirtualBox.
 (`systemd-detect-virt` returning `oracle`)
 `/usr/bin/vbox-guest-installer`
Description-md5: 09e095e928a4c962e728f72d712b4c34

Package: vm-config-dist
Status: install ok installed
Priority: optional
Section: misc
Installed-Size: 133
Maintainer: Patrick Schleizer <adrelanos@kicksecure.com>
Architecture: all
Version: 3:10.5-1
Replaces: power-savings-disable-in-vms, shared-folder-help
Depends: sudo, adduser, p7zip-full
Conffiles:
 /etc/dracut.conf.d/30-vm-config-dist.conf 4b17a68bed81773993a0c46d79148986
 /etc/gdm3/daemon.conf.dist b1f35c9655abcc3171af5c10ce4d8292
 /etc/profile.d/20_kde_screen_locker_disable_in_vms.sh e45dd471bc555b906c6c04b208f4066b
 /etc/profile.d/20_power_savings_disable_in_vms.sh bfef62e0edc770197204884b9fc3baea
 /etc/profile.d/20_software_rendering_in_vms.sh 32d99ab4948878c5c790145bdafa88ea
 /etc/skel/.config/xfce4/xfconf/xfce-perchannel-xml/displays.xml 573a4880ca28e8e094ea78fa76fb875e
Description: usability enhancements inside virtual machines
 Sets environment variable `QMLSCENE_DEVICE=softwarecontext` as workaround for
 "Automatic fallback to softwarecontext renderer".
 .
 It is not useful to open a screensaver or to power down the desktop for
 operating systems that are run inside VMs. There is no real display that could
 be saved and no real power that could be saved. From usability perspective it
 also is counter intuitive when looking at the VM window and only seeing a
 black screen. Therefore it makes sense to disable power savings in VMs.
 `/etc/X11/Xsession.d/20_kde_screen_locker_disable_in_vms.sh`
 `/etc/profile.d/20_power_savings_disable_in_vms.sh`
 `/etc/X11/Xsession.d/20_software_rendering_in_vms.sh`
 `/usr/share/kde-power-savings-disable-in-vms/kdedrc`
 `/usr/share/kde-screen-locker-disable-in-vms/kscreenlockerrc`
 .
 Disables screen locker when running in VMs because that is not useful either.
 .
 Makes setting up a shared folder for virtual machines a bit easier.
 .
  * Creates a folder `/mnt/shared` with `chmod 777`, adds a group
 "vboxsf", adds user "user" to group "vboxsf". Facilitates auto-mounting of
 shared folders.
 .
  * Helps using shared folders with VirtualBox and KVM a bit
 easier (as in requiring fewer manual steps from the user).
 .
  * `/lib/systemd/system/mnt-shared-vbox.service`
  * `/lib/systemd/system/mnt-shared-kvm.service`
 .
 Set screen resolution 1920x1080 by default for VM in VirtualBox and KVM.
 Workaround for low screen resolution 1024x768 at first boot. When using lower
 screen resolutions, Xfce will automatically scale down.
 `/etc/skel/.config/xfce4/xfconf/xfce-perchannel-xml/displays.xml`
 .
 Installs VirtualBox guest additions if package
 `virtualbox-guest-additions-iso` is installed if environment variable
 `dist_build_virtualbox=true` or if running inside VirtualBox.
 (`systemd-detect-virt` returning `oracle`)
 `/usr/bin/vbox-guest-installer`
Description-md5: 09e095e928a4c962e728f72d712b4c34
Homepage: https://github.com/Kicksecure/vm-config-dist

[user ~]%
  • SHA256 is OK and matches my locally built package.
myfind . | grep vm-config-dist | grep '.deb$' | xargs sha256sum
+ set -e
+ find . -type f -not -iwholename '*.git*'
41fc4cd7e2f97bdcf23ff80b91cbbc339aca3c60445ffaa4725147e4e28d048a  ./genmkfile-packages-result/vm-config-dist_10.5-1_all.deb
41fc4cd7e2f97bdcf23ff80b91cbbc339aca3c60445ffaa4725147e4e28d048a  ./aptrepo_local/kicksecure/pool/main/v/vm-config-dist/vm-config-dist_10.5-1_all.deb
41fc4cd7e2f97bdcf23ff80b91cbbc339aca3c60445ffaa4725147e4e28d048a  ./aptrepo_remote/kicksecure/pool/main/v/vm-config-dist/vm-config-dist_10.5-1_all.deb
  • The Installed-Size of the package on the VM is listed as one size, but the Packages file in Kicksecure's remote repo lists a different Installed-Size. Thus even though the debs are identical, apt believes the packages are different and wants to update to the remote version of the package as a result. See https://unix.stackexchange.com/questions/581291/why-apt-wants-to-upgrade-already-up-to-date-packagearchive.org. Why this is happening is unclear. Perhaps something is going wrong with using reprepro? See below.
# From https://deb.kicksecure.com/dists/bookworm/main/binary-amd64/Packages:
Package: vm-config-dist
...
Installed-Size: 135
...

# From /var/lib/dpkg/status from the linked OVA file:
Package: vm-config-dist
...
Installed-Size: 133
...
  • I did an OVA build in the background to see what Installed-Size it resulted in, but then accidentally deleted it, I can do redo the build and check it if desired.

str_replace utf-8 bug[edit]

str_replace %%replace-me-clearnet-replace-me%% kicksecure.com /etc/postfix/header_checks.db

Traceback (most recent call last):
  File "/usr/bin/str_replace", line 49, in <module>
    main()
  File "/usr/bin/str_replace", line 26, in main
    file_data = source_fh.read()
                ^^^^^^^^^^^^^^^^
  File "<frozen codecs>", line 322, in decode
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8e in position 54: invalid start byte
  • Low-priority, could be difficult to fix.

Qubes graphical-session.target missing bug[edit]

add date and time detection to archive.today frontend[edit]

  • This is necessary for the next task.
  • If a link has been archived once in the past, but is severely outdated, we should probably request that archive.today rearchive it. This requires that we know when archive.today archived each page.
  • (It might be worthwhile to detect when a link was added to the Wiki and use that as a deciding factor as to whether or not we should archive the link again. Might be doable by using the archive.today backups from Github.)
  • We decided to not attempt re-archiving already archived content, thus this is no longer needed for now.

mediawiki bot setup[edit]

rootless X11[edit]

  • only if doable with low effort such as just changing some configs (such as in lightdm config) or changing some installed packages
  • Would require switching away from LightDM or enabling rootless X11 support in LightDM, thus moving to backlog.

power9 RAM encryption research[edit]

  • todo

auto-detect, prompt for potential root devices in case the root= device is misconfigured or missing[edit]

dracut add support for undeclared CDLABEL[edit]

as discussed

live-build - Retry button in derivative-maker doesn't work[edit]

  • low priority, move to backlog please

Footnotes[edit]

Your support makes
all the difference!

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!

Retrieved from "https://www.kicksecure.com/w/index.php?title=Dev/todo&oldid=90592"