ToDo for Developers

From Kicksecure
< Dev
Jump to navigation Jump to search

TODO

TODO DEV[edit]

privleap - error - No authorized users or groups for action: 'tor-bootstrap-check'[edit]

  • was happening inside Qubes Whonix-Workstation Template only
  • error happened during upgrade from developers repository
Setting up privleap (3:2.3-1) ...
/etc/privleap/conf.d/systemcheck.conf:33:error:No authorized users or groups for action: 'tor-bootstrap-check'
WARNING: privleap configuration invalid. Not restarting privleapd.
  • file /etc/privleap/conf.d/systemcheck.conf already looks okay
[action:tor-bootstrap-check]
Command=/usr/libexec/helper-scripts/tor_bootstrap_check.py
AuthorizedGroups=sudo
AuthorizedUsers=user,sdwdate
TargetUser=debian-tor
TargetGroup=debian-tor
  • was happening insid Qubes Whonix-Gateway Template only
Setting up privleap (3:2.3-1) ...
/etc/privleap/conf.d/anon-connection-wizard.conf:1:error:No authorized users or groups for action: 'acw-tor-control-restart'
WARNING: privleap configuration invalid. Not restarting privleapd.
  • file /etc/privleap/conf.d/anon-connection-wizard.conf already looks good
[action:acw-tor-control-restart]
Command=/usr/libexec/anon-connection-wizard/acw-tor-control restart
AuthorizedGroups=sudo
AuthorizedUsers=user
  • Aaron: Attempted to fully upgrade a clean pair of Whonix-Gateway and Whonix-Workstation templates on Qubes OS R4.3 using the bookworm-developers repository. Cannot reproduce either bug, privleap installs, sets up, and has triggers run for it without issues, service is properly started and systemcheck works without errors.
  • Got another report from a user using the testers repository.
/etc/privleap/conf.d/systemcheck.conf:33:error:No authorized users or groups for
 action: 'tor-bootstrap-check'
WARNING: privleap configuration invalid. Not restarting privleapd. Run configura
tion check using: privleapd --check-config
  • This is perhaps because config check runs before new configuration files have been installed? Solution, run config check after installation of configuration files, i.e. after DEBHELPER token?

grml-debootstrap - downstream handling grub-cloud versus /etc/default/grub[edit]

  • After/if https://github.com/grml/grml-debootstrap/pull/299archive.org gets merged...
  • config-package-dev displace /etc/default/grub? Avoid "fighting" for configuration file ownership by moving the file out of the way.
  • Generate a configuration file using do_once. Probably not owned by any package.
  • Ship a default /etc/default/grub configuration file:
## Do not edit this file!
## Please create and add modifications to the following file instead:
## /etc/default/grub.d/50_user.cfg
##
## User documentation:
## https://www.kicksecure.com/wiki/grub
  • minor comment on link: https://www.kicksecure.com/wiki/grub (lower case) vs https://www.kicksecure.com/wiki/Grub (normal case) is OK. Preferring lower case for simplicity thanks to MediaWiki extension SaneCase.

grml-debootstrap - GRUB installation refactoring[edit]

  # Has chroot-script installed GRUB to MBR using grub-install (successfully), already?
  # chroot-script skips installation for unset ${GRUB}
  if [[ -z "${GRUB}" ]] || ! dd if="${GRUB}" bs=512 count=1 2>/dev/null | cat -v | grep -Fq GRUB; then
  • Split into multiple conditions?
  • More informational output.
  • Possible to leave GRUB installation to grml-deboostrap and leave it out from chroot-script?
  • potential bug / difficult to follow cod paths: chroot-script seems to set up grub-pc in some cases only. But if it does, then --vmefi would be skipped.
  • Better code documentation?

calamares - enable GRUB force_efi_extra_removable[edit]

  • todo
  • if applicable

GRUB - boot related enhancements[edit]

  • Are there any other boot related enhancements outstanding? If so, please create tickets for these.

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.

default password[edit]

set default shell for user sysmaint to zsh[edit]

  • todo

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

package refactoring - kicksecure-meta-packages vs qubes-whonix - #2[edit]

sudo apt dist-upgrade --no-install-recommends 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following package was automatically installed and is no longer required:
  qubes-core-agent-passwordless-root
Use 'sudo apt autoremove' to remove it.
The following NEW packages will be installed:
  codecrypt cython3 diceware dmeventd dosfstools extrepo fuse3 geoip-database kicksecure-cli kicksecure-default-applications-cli
  kicksecure-qubes-cli libaio1 libbytes-random-secure-perl libclone-perl libcrypt-passwdmd5-perl libcrypt-random-seed-perl
  libcrypto++8 libcryptx-perl libdevmapper-event1.02.1 libfftw3-double3 libfile-listing-perl libfuse3-3 libgeoip1 libhtml-parser-perl
  libhtml-tagset-perl libhtml-tree-perl libhttp-cookies-perl libhttp-date-perl libhttp-message-perl libhttp-negotiate-perl
  libio-html-perl libio-socket-ssl-perl liblvm2cmd2.03 liblwp-mediatypes-perl liblwp-protocol-https-perl libmath-random-isaac-perl
  libnet-http-perl libnet-ssleay-perl libntfs-3g89 libsnappy1v5 libtry-tiny-perl libwww-perl libwww-robotrules-perl
  libyaml-libyaml-perl lvm2 magic-wormhole makepasswd ntfs-3g perl-openssl-defaults pwgen python3-attr python3-autobahn
  python3-automat python3-base58 python3-bcrypt python3-cbor python3-click python3-colorama python3-constantly python3-cryptography
  python3-ecdsa python3-flatbuffers python3-geoip python3-hamcrest python3-hkdf python3-humanize python3-hyperlink
  python3-incremental python3-lz4 python3-mnemonic python3-msgpack python3-nacl python3-openssl python3-packaging python3-passlib
  python3-pyasn1 python3-pyasn1-modules python3-pyqrcode python3-service-identity python3-setuptools python3-snappy
  python3-sortedcontainers python3-spake2 python3-tqdm python3-trie python3-twisted python3-txaio python3-txtorcon python3-u-msgpack
  python3-ubjson python3-ujson python3-wsaccel python3-zope.interface
  • Workstation:
sudo apt dist-upgrade --no-install-recommends
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following package was automatically installed and is no longer required:
  qubes-core-agent-passwordless-root
Use 'sudo apt autoremove' to remove it.
The following NEW packages will be installed:
  dmeventd dosfstools firefox-esr kicksecure-cli kicksecure-desktop-applications-recommended kicksecure-qubes-cli kicksecure-qubes-gui libaio1 libdevmapper-event1.02.1 libgarcon-1-0
  libgarcon-common liblvm2cmd2.03 libntfs-3g89 libupower-glib3 libxklavier16 lvm2 ntfs-3g xfce4-helpers xfce4-settings

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]

KVM - verify AppArmor sVirt confinement operation[edit]

KVM - use rootless[edit]

KVM - port to unix domain socket based internal networking for Whonix-Gateway to Whonix-Workstation connections[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]

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]

GRUB - Debian packages grub-pc and grub-efi co-install-ability[edit]

user-sysmaint-split - Qubes - sysmaint boot features[edit]

user-sysmaint-split - Qubes - Selective sudo Access[edit]

Qubes kloak-alike tickets[edit]

calamares dual legacy + efi booting support[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
  • related PR: https://github.com/grml/grml-debootstrap/pull/302archive.org

privleap - post-review improvements[edit]

review safe-print[edit]

review and test IPv6 support pull requests[edit]

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]

  • there is /etc/pam.d/sudo-i for interactive and /etc/pam.d/sudo
  • pam has concepts of common-session-noninteractive vs common-session (non-interactive)
  • how could we on the PAM level notice if faillock is used interactively or non-interactively?
  • if non-interactive, skip faillock
  • if interactive, do not skip faillock
  • Bug reports:
  • Once we go sudoless, this will no longer be a concern except for VMs that aren't sudoless.

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]

ARCHIVED[edit]

ISO - use variable flavor_meta_packages_to_install[edit]

privleap - python-pam bug[edit]

  • error produced in anon-whonix
sudo journalctl --boot -u privleapd
Mar 03 11:30:21 host systemd[1]: Starting privleapd.service - privleap - Limited Privilege Escalation Framework...
Mar 03 11:30:21 host systemd[1]: Started privleapd.service - privleap - Limited Privilege Escalation Framework.
Mar 03 11:33:06 host privleapd[671]: handle_control_create_msg: INFO: Handled CREATE message for user 'user', socket created
Mar 03 11:33:07 host python3[671]: pam_unix(privleapd:session): session opened for user debian-tor(uid=107) by (uid=0)
Mar 03 11:33:07 host python3[671]: pam_succeed_if(privleapd:session): requirement "uid eq 0" not met by user "debian-tor"
Mar 03 11:33:07 host privleapd[671]: handle_control_create_msg: WARNING: User 'debian-tor' is not allowed to have a comm socket
Mar 03 11:33:07 host privleapd[671]: handle_comm_session: INFO: Triggered action 'tor-circuit-established-check'
  • Aaron: The PAM message is perfectly normal, it's triggered by this snippet in /etc/pam.d/common-session:
session [success=1 default=ignore] pam_succeed_if.so uid eq 0
session optional pam_umask.so umask=027
  • This snippet says "set the umask for the newly logged-in user to 027 if they aren't root. If they are root, skip over the umask setting. When running an action as debian-tor, this will end up showing a message that the UID check didn't pass, meaning that the umask will be set. This is an intentional part of how we implement stricter umask settings.
  • The issue stating that debian-tor is not allowed to have a comm socket is normal, because debian-tor (for some reason unknown to me) has a running user session in the anon-whonix VM. This means that it triggers a leapctl@UID.service unit for itself like any other logged-in user, but because it isn't listed as an allowed user, that service doesn't start (by design). Therefore this isn't a problem, though it's curious that debian-tor is logged in...

bookworm-backports-staging[edit]

  • https://fasttrack.debian.net/archive.org mentions deb https://fasttrack.debian.net/debian-fasttrack/archive.org bookworm-backports-staging main contrib
  • Is this new?
    • Aaron: Does not appear to be new, this was how things were done in Bullseye as well.
  • Since Kicksecure enables fasttrack by default, should probably enable bookworm-backports-staging by default too?
    • Aaron: Yes, we should. "Staging" is usually scary and indicates there could be package breakage, but in this instance it's effectively identical to the normal backports repo but allows packages in that don't fit the normal backports rules (yet). This isn't a place for doing dangerous operations like I initially thought.

investigate why debian-tor has a login on Whonix-Workstation[edit]

Qubes APT pinning ticket[edit]

privleap - keep trying to start leapctl@1000.service[edit]

Mar 03 11:09:50 host systemd[1]: leapctl@1000.service: Failed with result 'exit-code'.
Mar 03 11:09:50 host systemd[1]: Stopped leapctl@1000.service - leapctl - Enable access to privleap for each user.
Mar 03 11:09:50 host systemd[1]: Starting leapctl@1000.service - leapctl - Enable access to privleap for each user...
Mar 03 11:09:50 host leapctl[40455]: ERROR: Could not connect to privleapd!
Mar 03 11:09:50 host systemd[1]: leapctl@1000.service: Main process exited, code=exited, status=1/FAILURE
Mar 03 11:09:50 host systemd[1]: leapctl@1000.service: Failed with result 'exit-code'.

privleap - leaprun - consider supporting end-of-options[edit]

privleap - consider using end-of-options[edit]

        ["/usr/bin/bash", "-c", desired_action.action_command],
  • minor: useful to change to...?
        ["/usr/bin/bash", "-c", "--", desired_action.action_command],

privleap - harden and polish[edit]

  • Continue fixing and discussing issues found by Ben Grande and others.
  • Should be done, only remaining issue that seems potentially concerning is https://github.com/ArrayBolt3/privleap/issues/11archive.org which may or may be something that needs fixed.
  • Patrick: merged

privleap - abolish simple all users allowed fallback[edit]

[command:echo-hello]
Command=echo 'Hi!'

fix up policy-rc.d script in user-sysmaint-split[edit]

privleap - implement config reload without restart[edit]

  • https://github.com/ArrayBolt3/privleap/issues/12archive.org
  • configuration fast hash based?
  • Current implementation works via an explicit restart command that can be sent by leapctl. Performance doesn't seem to be an issue doing a total reload each time, can revisit hashing if performance becomes a problem.
  • Click = Copy Copied to clipboard! sudo systemctl reload privleapd

user-sysmaint-split - document policy-rc.d[edit]

privleap postinst deb-systemd-invoke bug[edit]

#####################################################################
## INFO: BEGIN: privleap postinst configure' '3:1.7-1
#####################################################################
'
+ case "$1" in
+ deb-systemd-helper enable privleapd.service
+ deb-systemd-helper enable leapctl@.service
+ start_privleapd
+ deb-systemd-invoke restart privleapd.service
Could not execute systemctl:  at /usr/bin/deb-systemd-invoke line 145.

[template gateway user ~]% sudo DEBDEBUG=1 dpkg --configure -a
Setting up privleap (3:1.9-1) ...
++ [[ -v disable_echo ]]
++ disable_echo=
++ '[' '' = true ']'
++ colors
++ alt=
++ ealt=
++ hide=
++ show=
++ save=
++ load=
++ bold=
++ stout=
++ estout=
++ under=
++ eunder=
++ reset=
++ blink=
++ italic=
++ eitalic=
++ red=
++ green=
++ yellow=
++ blue=
++ magenta=
++ cyan=
++ white=
++ default=
++ eed=
++ eel=
++ ebl=
++ ewl=
++ draw=
++ back=
++ test -n ''
++ test -n ''
++ [[ -v TERM ]]
++ '[' xterm-256color = '' ']'
++ [[ -t 2 ]]
+++ type -t exception_handler_general
++ '[' '' = function ']'
+++ trap -p ERR
++ '[' '' = '' ']'
++ trap error_handler_pre ERR
++ bash -n /usr/libexec/helper-scripts/pre.bsh
++ bash -n /var/lib/dpkg/info/privleap.postinst
++ own_filename=privleap.postinst
++ source_config_folder
++ [[ -v DPKG_MAINTSCRIPT_PACKAGE ]]
++ '[' privleap = '' ']'
++ pre_bsh_settings_folder=privleap_maint.d
++ shopt -s nullglob
++ local i
++ true 'folder 1: /etc/privleap_maint.d/*.conf'
++ true 'folder 2: /usr/local/etc/privleap_maint.d/*.conf'
++ shopt -u nullglob
++ check_scripts_to_skip
++ [[ -v SKIP_SCRIPTS ]]
++ SKIP_SCRIPTS=
++ local skip_script
+ set -e
+ true '
#####################################################################
## INFO: BEGIN: privleap postinst configure' '3:1.7-1
#####################################################################
'
+ restarted_once=no
+ case "$1" in
+ deb-systemd-helper enable privleapd.service
+ deb-systemd-helper enable leapctl@.service
+ start_privleapd
+ '[' no = yes ']'
++ command -v systemctl
+ '[' '!' -x /usr/bin/systemctl ']'
+ deb-systemd-invoke restart privleapd.service
Could not execute systemctl:  at /usr/bin/deb-systemd-invoke line 145.
++ error_handler_pre

privleap - run config check from postinst[edit]

privleap - bug duplicate action tor-verify-config[edit]

Feb 20 05:37:04 host privleapd[15069]: parse_config_files: CRITICAL: Error parsing config: '/etc/privleap/conf.d/systemcheck.conf:26:error:Duplicate action found: 'tor-verify-config''

privleap - change action header format[edit]

user-sysmaint-split - consider using policyrcd-script-zg2[edit]

  • todo
  • Aaron: Looks like it introduces more complexity than it fixes:
    • It doesn't actually support drop directories as hoped. It just looks for a script in:
      • Whatever location is specified by a hardcoded config file /etc/zg-policy-rc.d.conf
      • Whatever location is specified by a hardcoded environment variable CONFFILE
      • One of two hardcoded locations (/usr/local/sbin/policy-rc.d or /etc/policy-rc.d)
    • It only executes one script. Ultimately this is no better than the functionality given by just using update-alternatives.
    • It warns in the manpage that there may be many bugs. The script isn't that long, but it has lots of (seemingly unnecessary?) automake stuff surrounding it, which worries me.
    • IMO, it will be easier to just fiddle with update-alternatives when we need to tweak policy-rc.d than to use this.

sdwdate-gui - port qrexec temporary file to tmpfiles.d[edit]

sdwdate-gui - /run/user/1000 owned by wrong user[edit]

user-sysmaint-split - consider using policy-rcd-declarative-deny-all or alike in sysmaint mode[edit]

privleap - start early before other systemd units such as sdwdate[edit]

privleap - investigate qubes crashes[edit]

user-sysmaint-split - account bob breaks upgrade[edit]

  • todo
  • Should now be fixed, also made a bunch of other improvements, closing issues filed by Ben Grande.

user-sysmaint-split - remove dependency on lightdm[edit]

user-sysmaint-split - Qubes tb-updater - fix disposable VM support[edit]

user-sysmaint-split - test sudoless upgrade-nonroot[edit]

read 3mdeb RAM decay research[edit]

live-build - local repository support[edit]

user-sysmaint-split - Qubes - sysmaint-boot.target - upstream feature request[edit]

privleap - add crash recovery[edit]

  • If privleapd crashes on a system with user-sysmaint-split installed, the user will be left with no way to run privileged operations until the next reboot. Even without user-sysmaint-split, many of the sudoless application ports will function improperly if privleapd isn't running.
  • Make privleapd resilient to crashes:
    • Add a watchdog timeout to the systemd unit
    • Add code to privleapd that occasionally pings systemd to let it know it's still running via sdnotify
    • Handle user login/logout comm sockets using a systemd service template so that non-persistent user sockets can be automatically recreated on restart
  • Code changes:

user-sysmaint-split - privleap - use systemd notify[edit]

  • sdwdate uses sd-notify. Please look at it (or something else) as an example on how to implement it.
  • please implement sd-notify in privleap
  • reason: reliably notify systemd when the daemon is ready. This will avoid any hardcoded "sleep 1" in Debian postinst and will generally increase the reliability of privleap. Should it ever be stuck, systemd would detect this and restart privleap.
  • systemd unit file changes:
[Service]
Type=notify
TimeoutSec=30 ## needs adjustment
WatchdogSec=200m ## needs adjustment
Restart=always
  • usr/lib/python3/dist-packages/sdwdate/sdwdate.py
usr/lib/python3/dist-packages/sdwdate/sdwdate.py:import sdnotify
usr/lib/python3/dist-packages/sdwdate/sdwdate.py:SDNOTIFY_OBJECT = sdnotify.SystemdNotifier()
usr/lib/python3/dist-packages/sdwdate/sdwdate.py:SDNOTIFY_OBJECT.notify("READY=1")
usr/lib/python3/dist-packages/sdwdate/sdwdate.py:SDNOTIFY_OBJECT.notify("STATUS=Starting...")
usr/lib/python3/dist-packages/sdwdate/sdwdate.py:    SDNOTIFY_OBJECT.notify("STATUS=Shutting down...")
usr/lib/python3/dist-packages/sdwdate/sdwdate.py:    SDNOTIFY_OBJECT.notify("WATCHDOG=1")
usr/lib/python3/dist-packages/sdwdate/sdwdate.py:    SDNOTIFY_OBJECT.notify("STOPPING=1")
usr/lib/python3/dist-packages/sdwdate/sdwdate.py:            SDNOTIFY_OBJECT.notify("WATCHDOG=1")
usr/lib/python3/dist-packages/sdwdate/sdwdate.py:            SDNOTIFY_OBJECT.notify(msg)
usr/lib/python3/dist-packages/sdwdate/sdwdate.py:        SDNOTIFY_OBJECT.notify("WATCHDOG=1")
usr/lib/python3/dist-packages/sdwdate/sdwdate.py:        msg_for_sdnotify = "STATUS=" + msg
usr/lib/python3/dist-packages/sdwdate/sdwdate.py:        SDNOTIFY_OBJECT.notify(msg_for_sdnotify)
usr/lib/python3/dist-packages/sdwdate/sdwdate.py:        SDNOTIFY_OBJECT.notify("WATCHDOG=1")
usr/lib/python3/dist-packages/sdwdate/sdwdate.py:        SDNOTIFY_OBJECT.notify("WATCHDOG=1")
  • Added basic support, also got the postinst script working properly and passing lintian. I don't know if watchdog support is desirable, since comm sockets will be lost during a restart and automatically recreating them may not always be desirable.
  • Patrick: merged

coding style - avoid which - use command -v[edit]

  • which, use command -v instead. This is because which is an external binary (minor reason) and produces stdout if a binary was found, which can be slightly confusing (major reason).
  • documented on Dev/bash just now
  • task can be moved to archived after reading
  • Aaron: Will do.

lintian - use lintian locally during package build process[edit]

  • lintian is already run during the build process.
/usr/share/genmkfile/make-helper-one.bsh: INFO: You can find your deb file here: /home/user/derivative-binary/genmkfile-packages-result/privleap_1.3-1_all.deb
/usr/share/genmkfile/make-helper-one.bsh: INFO: make_use_lintian='' - Autodetecting if lintian is installed...
/usr/share/genmkfile/make-helper-one.bsh: INFO: lintian auto detected, using it...
lintian           --suppress-tags missing-tests-control          --suppress-tags systemd-service-file-missing-documentation-key          --suppress-tags orig-tarball-missing-upstream-signature          --suppress-tags package-supports-alternative-init-but-no-init.d-script          --suppress-tags no-manual-page          --quiet          --pedantic          --info          --display-info            "/home/user/derivative-binary/genmkfile-packages-result/privleap_1.3-1_amd64.changes"
/usr/share/genmkfile/make-helper-one.bsh: INFO: lintian exit code: 0
/usr/share/genmkfile/make-helper-one.bsh: INFO: lintian output:
################################################################################
N:
W: privleap: maintainer-script-calls-systemctl [postinst:41]
  • This breaks package build. By undocumented convention, all packages produce result in lintian exit code 0 and no lintian output. All lintian warnings are either fixed, suppressed or have lintian exception configurations.
  • Could you please add to your local build tools to run genmkfile lintian?
  • Aaron: Will do, usually I use genmkfile deb-pkg which runs this but I've been ignoring the output incorrectly.

live-build - --debian-installer-distribution git security impact research[edit]

  • TODO research: would --debian-installer-distribution git verify software signatures or still be vulnerable to HTTP / HTTPS based attacks?
  • Aaron: Yes, this is still vulnerable. udebs are downloaded directly even when building the installer from source. Additionally, you can't use a source-built installer to create a Bookworm ISO anymore - only Trixie and newer works because Bookworm lacks udebs sufficiently new enough for the debian-installer build to work.

user-sysmaint-split - quick uninstall boot option[edit]

    def uninstall():
        subprocess.run(["/usr/libexec/helper-scripts/terminal-wrapper",
                       "/usr/bin/sudo", "/usr/bin/apt", "purge",
                       "user-sysmaint-split"])
        subprocess.run(["/usr/sbin/reboot"])

user-sysmaint-split - privleap - add a trigger to reload privleap once its configuration folder changed[edit]

user-sysmaint-split - privleap - start privleap after installation[edit]

  • if possible (to avoid issues after installation)
  • Did as part of adding a trigger to privleap.

user-sysmaint-split - privleap - sdwdate-gui - temp folder[edit]

echo "$QREXEC_REMOTE_DOMAIN $1" | tee /tmp/sdwdate-gui-tmp-status

sync fork of live-build with upstream[edit]

user-sysmaint-split - privleap - breaks Qubes gui[edit]

  • whonix-workstation-17-dvm is no longer starting, likely due to the issue below
  • Tested, seems to now be resolved.

user-sysmaint-split - privleap - close stdin[edit]

  • close stdin, since not available anyhow
  • this is to avoid programs waiting for input forever, which will never come
  • Done in latest privleap code.

user-sysmaint-split - privleap - usability-misc privleap configuration bug[edit]

Feb 06 18:32:29 host systemd[1]: Started privleapd.service - privleap - Limited Privilege Escalation Framework.
Feb 06 18:32:29 host privleapd[877]: parse_config_files: CRITICAL: Failed to load config file '/etc/privleap/conf.d/usability-misc.conf'!
Feb 06 18:32:29 host privleapd[877]: Traceback (most recent call last):
Feb 06 18:32:29 host privleapd[877]:   File "/usr/lib/python3/dist-packages/privleap/privleapd.py", line 595, in parse_config_files
Feb 06 18:32:29 host privleapd[877]:     = pl.PrivleapCommon.parse_config_file(f.read())
Feb 06 18:32:29 host privleapd[877]:       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Feb 06 18:32:29 host privleapd[877]:   File "/usr/lib/python3/dist-packages/privleap/privleap.py", line 1010, in parse_config_file
Feb 06 18:32:29 host privleapd[877]:     action_output_list.append(PrivleapAction(current_action_name,
Feb 06 18:32:29 host privleapd[877]:                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Feb 06 18:32:29 host privleapd[877]:   File "/usr/lib/python3/dist-packages/privleap/privleap.py", line 830, in __init__
Feb 06 18:32:29 host privleapd[877]:     raise ValueError(f"User '{raw_auth_user}' specified by "
Feb 06 18:32:29 host privleapd[877]: ValueError: User 'sysmaint' specified by field 'AuthorizedUsers' of action 'upgrade-nonroot-wrapper' does not exist!
Feb 06 18:32:29 host systemd[1]: privleapd.service: Main process exited, code=exited, status=1/FAILURE
Feb 06 18:32:29 host systemd[1]: privleapd.service: Failed with result 'exit-code'.

user-sysmaint-split - privleap - setup-dist and anon-connection-wizard[edit]

debian/control:         pkexec,
usr/lib/python3/dist-packages/anon_connection_wizard/tor_status.py:    command = ['pkexec', '/usr/libexec/anon-connection-wizard/acw-write-torrc', temp_file_path]
usr/lib/python3/dist-packages/anon_connection_wizard/anon_connection_wizard.py:                    command = ['pkexec', '/usr/libexec/anon-connection-wizard/acw-write-torrc', Common.torrc_tmp_file_path]
  • tor-control-panel:
packages/kicksecure/tor-control-panel/debian/control:         pkexec,
  • Patrick: Done. setup-dist is now using privleap for Tor enable/disable. Please review and move to archived if OK.
  • Aaron: Makes sense to me, don't see any problems with it.

user-sysmaint-split - implement sudoless[edit]

user-sysmaint-split - implement sudoless #2[edit]

    • Additional things done:
      • grep through entire Kicksecure and Whonix codebases for all uses of sudo, replace with privleap where appropriate
      • grep through entire Kicksecure and Whonix codebases for all uses of pkexec, replace with privleap where appropriate

Port maybe needed? What should happen if a user runs repository-dist in user mode? 

packages/kicksecure/repository-dist/debian/control:Depends: pkexec,
packages/kicksecure/repository-dist/usr/lib/python3/dist-packages/repository_dist_wizard/repository_dist_wizard.py:                    command = ['pkexec', 'repository-dist', '--disable']
packages/kicksecure/repository-dist/usr/lib/python3/dist-packages/repository_dist_wizard/repository_dist_wizard.py:                command = ['pkexec', 'repository-dist', '--enable'] + repository

Port not needed because runs in sysmaint mode: 

packages/kicksecure/calamares-settings-debian/calamares-install-debian:pkexec calamares
packages/kicksecure/calamares-settings-debian/debian/control:         pkexec,

packages/kicksecure/live-config-dist/debian/control:Depends: helper-scripts, pkexec, rsync, libglib2.0-bin, xdg-user-dirs,
packages/kicksecure/live-config-dist/usr/bin/install-host:if ! [ -x '/usr/bin/pkexec' ] || ! [ -x '/usr/bin/sudo' ]; then
packages/kicksecure/live-config-dist/usr/bin/install-host:The pkexec or sudo command is not executable by the current user. Installation cannot proceed. You may need to log in as user 'sysmaint' to resolve this.
packages/kicksecure/live-config-dist/usr/bin/install-host:pkexec install-host-calamares-wrapper
packages/kicksecure/live-config-dist/usr/share/polkit-1/actions/com.kicksecure.install-host-calamares-wrapper.policy: <action id="com.kicksecure.install-host-calamares-wrapper.policy.pkexec.run">
'/usr/bin/pkexec'

Will cause issue https://forums.whonix.org/t/getting-setup-dist-error-in-whonix-gateway/21162archive.org - separate ticket created: 

packages/kicksecure/tor-control-panel/debian/control:         pkexec,

packages/kicksecure/anon-connection-wizard/debian/control:         pkexec,
packages/kicksecure/anon-connection-wizard/usr/lib/python3/dist-packages/anon_connection_wizard/tor_status.py:    command = ['pkexec', '/usr/libexec/anon-connection-wizard/acw-write-torrc', temp_file_path]
packages/kicksecure/anon-connection-wizard/usr/lib/python3/dist-packages/anon_connection_wizard/anon_connection_wizard.py:                    command = ['pkexec', '/usr/libexec/anon-connection-wizard/acw-write-torrc', Common.torrc_tmp_file_path]

Port not needed (runs in sysmaint mode or not important): 

packages/kicksecure/kicksecure-meta-packages/debian/control:         pkexec,
packages/kicksecure/sysmaint-panel/debian/control:         pkexec,

packages/kicksecure/tb-starter/usr/bin/torbrowser:      if ! pkexec /usr/share/tb-profile-i2p/enable-i2p; then
packages/kicksecure/tb-starter/usr/bin/torbrowser:Most likely user-sysmaint-split is installed and you are booted into 'PERSISTENT mode USER' or 'LIVE mode USER'. To enable i2p, reboot and select 'PERSISTENT mode SYSMAINT', then open a terminal and run 'pkexec /usr/share/tb-profile-i2p/enable-i2p'. More info: <a href=https://www.kicksecure.com/wiki/Sysmaint>https://www.kicksecure.com/wiki/Sysmaint</a>"
packages/kicksecure/tb-starter/usr/bin/torbrowser:   ## This effectively results in a one time pkexec prompt for users of

Port not needed, not really using pkexec: 

packages/kicksecure/user-sysmaint-split/debian/control: pkexec) inaccessible to limited user accounts such as user "user".
packages/kicksecure/user-sysmaint-split/usr/lib/permission-hardener.d/20_user-sysmaint-split.conf:/usr/bin/pkexec 4750 root sysmaint

packages/kicksecure/security-misc/debian/security-misc.postinst:   if [ "$(stat --format '%G' /usr/bin/pkexec)" = 'sysmaint' ]; then
packages/kicksecure/security-misc/debian/security-misc.postinst:      if ! [[ "${dpkg_statoverride_list}" =~ '/usr/bin/pkexec' ]]; then
packages/kicksecure/security-misc/debian/security-misc.postinst:         dpkg-statoverride --admindir "${new_mode_dir}" --add 'root' 'sysmaint' '4750' 

packages/kicksecure/developer-meta-files/usr/bin/dm-packaging-helper-script:      'Depends: pkexec' \
packages/kicksecure/security-misc/debian/security-misc.undisplace:/usr/bin/pkexec.security-misc
packages/kicksecure/security-misc/usr/lib/systemd/system-preset/50-security-misc.preset:## Disable due to pkexec issues.
packages/kicksecure/security-misc/usr/lib/permission-hardener.d/25_default_whitelist_policykit.conf:/usr/bin/pkexec exactwhitelist
packages/kicksecure/security-misc/usr/lib/permission-hardener.d/25_default_whitelist_policykit.conf:/usr/bin/pkexec.security-misc-orig exactwhitelist
packages/kicksecure/security-misc/usr/lib/permission-hardener.d/25_default_whitelist_policykit.conf:## May be safe to disable for users other than sysmaint similar to what was done with pkexec and sudo,
packages/kicksecure/security-misc/usr/share/lintian/overrides/security-misc:security-misc: no-manual-page [usr/bin/pkexec.security-misc]
packages/kicksecure/security-misc/usr/share/security-misc/permission-hardener-existing-mode-legacy-hardcoded:root root 4755 /usr/bin/pkexec

user-sysmaint-split - passwordless login breaks when uninstalled[edit]

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
    • Used several different search terms that could reference X11, adding additional documentation where needed.

user-sysmaint-split - port upgrade-nonroot to privleap[edit]

if ! [ -f "/etc/privleapd/pid" ] ; then
  echo "$0: ERROR: code 1: TODO"
  exit 1
fi

if ! [ -d "/proc/$(cat /etc/privleapd/pid)" ] ; then
  echo "$0: ERROR: code 2: TODO"
  exit 1
fi

if ! [ -e "/etc/privleapd/comm/$(id -nu)" ]; then
  echo "$0: ERROR: code 3: TODO"
  exit 1
fi

user-sysmaint-split - avoid /etc as pid file location[edit]

  • File location /etc/privleapd/pid seems unusual.
    • Aaron: We're not using /etc, we're using /run. Details shared in chat.

user-sysmaint-split - bind-mounts based passwordless privilege escalation wrapper[edit]

  • implemented using overlays (bind mounts)
  • passwordless privilege escalation tools in Qubes Template
  • useful error message in Non-Qubes user mode and Qubes App Qube. untested pseudocode:
#!/bin/bash

## Copyright (C) 2025 - 2025 ENCRYPTED SUPPORT LLC <adrelanos@whonix.org>
## See the file COPYING for copying conditions.

if test -x /path/to/real/sudo ; then
   exec /path/to/real/sudo "$@"
fi

## Avoiding 'source'ing external libraries to avoid additional AppArmor issues.
## 'source' is a bashism.
#. /usr/libexec/helper-scripts/get_colors.sh

if test -f /usr/share/whonix/marker ; then
   project_website="https://www.whonix.org"
else
   project_website="https://www.kicksecure.com"
fi

echo 'ERROR: This account lacks administrative ("root") capabilities. See: ${project_website}/wiki/sysmaint' >&2

## Let the attempt to execute 'sudo' show the actual error message.
/path/to/real/sudo "$@"
  • After attempted implementation and running into roadblocks, we no longer want to do this. It's a hack to work around missing Qubes OS features that we should be developing.

qubes-template-kicksecure - Thunar - icons missing[edit]

qubes-template-kicksecure - #3[edit]

  • rebuild qubes-template-kicksecure
  • Now good enough to be built for qubes-community-testing repository by Qubes?
  • If not, please create follow-up tickets.
  • Patrick: Moved Thunar issue into its own ticket since not a blocker.
  • Patrick: Next goal is to update https://github.com/QubesOS/qubes-issues/issues/9573archive.org by posting a comment. Such as requesting that Qubes builds the Template for the community-testing repository. Selective broken applications are acceptable (such as Thunar). This is to allow upstream Qubes time to review, try to build the template, notify downstream Kicksecure of potentially yet unknown issues.
    • Only immediately apparent issue I see is that we still have the bookworm-testers repo specified as the Kicksecure repo to use for the build process, whereas user-sysmaint-split is only available in bookworm-developers. This makes the build fail until the template-kicksecure code repo is manually edited to specify the correct source repo.

user-sysmaint-split - review helper-scripts[edit]

privleap - compare what privleap is doing versus sudo and doas regarding environment[edit]

    action_env["HOME"] = user_info.pw_dir
    action_env["LOGNAME"] = user_info.pw_name
    action_env["PWD"] = user_info.pw_dir
    action_env["USER"] = user_info.pw_name
  • please check what sudo / doas is doing for completeness sake
  • env vars
  • any other setup?
    • doas (https://man.openbsd.org/doas.1archive.org):
      • HOME - We're already setting this.
      • LOGNAME - We're already setting this.
      • PATH - Set by systemd and inherited from privleapd, this is hardcoded to a known-good value.
      • SHELL - Useful to set, now hardcoded in privleapd to /usr/bin/bash (since that's the shell privleapd uses to run actions).
      • USER - We're already setting this.
      • umask - Default, inherited from systemd, probably do not want to change this.
      • DISPLAY - Usually specifies the active X11 display the process is running on. privleapd runs as a service and will have no X11 display, thus this is useless for us.
      • TERM - Specifies what terminal is in use. Probably also useless, processes run by privleapd are not given a PTY.
      • PWD - Not changed by doas. We're setting it, but we're also not changing the process's actual current working directory, which could potentially result in malfunctions. Fixed.
    • sudo (https://man7.org/linux/man-pages/man8/sudo.8.html#ENVIRONMENTarchive.org):
      • EDITOR - Used by sudo, but doesn't appear to be set by it.
      • MAIL - Set to the mail spool of the target user in some instances. This is empty on Kubuntu 24.04 and Kicksecure 17, and is set to /var/mail/user on a mostly minimal Debian 12 VM (that path doesn't actually exist on the VM though, strangely enough). Probably not useful.
      • HOME - We're already setting this.
      • LOGNAME - We're already setting this.
      • PATH - See above in doas section.
      • SHELL - See above in doas section.
      • SUDO_ASKPASS - Specific to sudo, not set by sudo.
      • SUDO_COMMAND - Specific to sudo, set to the command that is run by sudo. Potentially useful but also sudo-specific, probably not needed?
      • SUDO_EDITOR - Specific to sudo, not set by sudo.
      • SUDO_GID - Specific to sudo, set to the GID of the user who invoked sudo. Potentially useful, easy to implement in a secure manner. Desirable?
      • SUDO_PROMPT - Specific to sudo, not set by sudo.
      • SUDO_PS1 - Specific to sudo, not set by sudo, most likely only affects interactive shells which privleap doesn't support anyway.
      • SUDO_UID - Specific to sudo, set to the UID of the user who invoked sudo. Potentially useful, easy to implement in a secure manner. Desirable?
      • SUDO_USER - Specific to sudo, set to the login name of the user who invoked sudo. Potentially useful, easy to implement in a secure manner, but could potentially be used for malicious purposes if the user has a Unicode-based username? See https://lwn.net/Articles/1000485/archive.org. Redundant if SUDO_UID is implemented, probably we shouldn't set this.
      • USER - We're already setting this.
      • VISUAL - Used by sudo, but doesn't appear to be set by it.

privleap - environment variables security[edit]

  • consider account user setting malicious environment variables (length based buffer overflow, code substitution $(...) / `...` syntax)
    • This should not be a problem. Environment variables cannot be inherited from the user that calls privleap because they are not transmitted by the client to the server. All actions launched by privleap will inherit their environment from the privleapd server, which inherits its environment directly from systemd. Environment variables that aren't inherited directly are currently derived from basic user info configured in root-owned files, thus not a security risk.
    • Will keep this in mind if more environment variables need tweaked.

privleap - code improvements[edit]

  • Patrick:
    • Output internal configuration to stdout? At least when debug mode is enabled. This would be useful to look into what actually got parsed.
    • Worthwhile to simplify?
        self.auth_user = auth_user if auth_user != "" else None
        self.auth_group = auth_group if auth_user != "" else None

        self.auth_user = auth_user
        self.auth_group = auth_group

        if desired_action.auth_user is not None:

        if desired_action.auth_user is not "":
      • These are already either simplified, or can't reasonably be simplified further. In particular None and "" are not interchangeable and explicitly using None in Python is preferable when possible.
    • Print first (more likely it will succeed and leave a log entry). Run the try/except block after?
                try:
                    comm_session.send_msg(
                        pl.PrivleapCommServerUnauthorizedMsg())
                except Exception:
                    print("handle_comm_session: Could not send UNAUTHORIZED")
                    print(traceback.format_exc())

                print("handle_comm_session: User is not authorized to run "
                    "action '"
                    + desired_action.action_name
                    + "'")
    • Generally, do the safe action print to stdout (which ends up in journal) first. Later do things which might hang in theory.
      • Done.

user-sysmaint-split - privleap - improvements[edit]

  • user_name validation - enforce maximum user name length: user_name variable should have a reasonable maximum string length
  • move user_name validation into a dedicated function?
  • maybe signal name could be validated using the same function?
  • Added requested features. https://github.com/ArrayBolt3/privleap/commit/6c653e64da4959de2b53b72ec49835c01808204barchive.org Rather than enforcing a maximum user name length though, I enforced a maximum client-sent message length since that was more comprehensive and easier to do in an efficient manner.

user-sysmaint-split - privleap - implement user switch - runas[edit]

  • please implement, if needed
  • already done, will use it where needed

privleap[edit]

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

user-sysmaint-split - refactor pkexec support[edit]

user-sysmaint-split - sysmaint-boot.target should allow SSH[edit]

permission-hardener v2 - add easy debug feature[edit]

permission-hardener v2 - repetitive polkit-agent-helper-1 messages[edit]

  • background: The polkit-agent-helper-1 config snippet went thorough 2 several revisions. 1) usrmerge was dropped 2) symlink /usr/lib/policykit-1/polkit-agent-helper-1 that links to actual SUID /usr/lib/polkit-1/polkit-agent-helper-1.
    • The bug already happened after revision 1. (Maybe even earlier.)
  • on every run:
  • only /usr/lib/polkit-1/polkit-agent-helper-1 shows up in print-policy, as expected
  • bug: older revisions still show up in state, but should not?
  • Bug fix: https://github.com/ArrayBolt3/security-misc/tree/arraybolt3/permission-hardener-symlink-fixarchive.org Fully resolves symlinks, rejects hardlinks.

user-sysmaint-split - research Qubes user to root isolation[edit]

user-sysmaint-split - passwordless-root fixes[edit]

  • /usr/bin/passwordless-root needs fixes?
  • add dummy-dependency --cached option to avoid creating the dummy package at every boot
    • Patrick: Done.
  • store in a persistent directory
    • Patrick: Done. /var/lib/dummy-dependency/dummy-user-sysmaint-split_99_all.deb
  • make directory persistent using Qubes bind-dirs

security - upgrade comment[edit]

continuous review[edit]

  • before merging newer derivative-maker git tag, please compare doing theoretic review
  • please discuss and/or open tickets in case commentary is applicable
  • +1, will do this regularly.

permission-hardener - make migration code faster[edit]

  • The following is too slow. Can take more than a minute on a fast system. Appears as if the system is broken.
   readarray -t custom_hardening_arr < <(dpkg -V | awk '/permission-hardener.d/{ print $NF }')

readarray -t custom_hardening_arr < <(find /usr/lib/permission-hardener.d /etc/permission-hardener.d -type f)

+ modified_pkg_data_str='missing     /usr/lib/permission-hardener.d/20_user-sysmaint-split.conf'

user-sysmaint-split - fix pkexec for sysmaint user[edit]

  • Aaron:
    • Note, gparted and zulucrypt probably *should* work in sysmaint mode. pkexec also doesn't work in sysmaint mode. I believe the reason they don't work is

because there's likely a polkit-related systemd unit we need to be depending on in sysmaint-boot.target.

user-sysmaint-split - Whonix documentation review[edit]

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.
    • Patrick: Done.
  • Plan for Kicksecure-Qubes and Qubes-Whonix-Workstation?
    • No longer install qubes-core-agent-passwordless-root by default.
      • Patrick: Done.
    • Install user-sysmaint-split by default in new Qubes-Whonix-Workstation templates.
      • Patrick: Done.
    • Install qubes-core-agent-passwordless-root by default in new Qubes-Whonix-Gateway templates.
      • Patrick: Done.
    • Users could not really use account sysmaint due to missing X server. Instead, user needs to use a Qubes Root Console.
      • Patrick: Done.
  • Plan for Qubes-Whonix-Gateway?
  • user documentation
  • suggestions for create user `admin` by default and add user `admin` to group `sudo` by defaultarchive.org?

legacy-dist - enable GRUB force_efi_extra_removable[edit]

debconf-set-selections <<< 'grub-efi-arm64 grub2/force_efi_extra_removable
  • please add to https://github.com/Kicksecure/legacy-distarchive.org (postinst?), if sane
  • code needs to be defensive. GRUB might not be installed. (Qubes; chroot; direct kernel boot; unknown)
  • Risky to do for existing users (might overwrite other bootloaders). Therefore not doing this.

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.
  • Branch with enhanced metapackages: https://github.com/ArrayBolt3/kicksecure-meta-packages/tree/arraybolt3/kicksecure-qubesarchive.org
    • Was not able to test this locally, couldn't figure out how to get a locally built package to be used in a Kicksecure build. Need to research that further in the future. I was able to build the package with genmkfile though.
      • Patrick: Merged, built and uploaded and tested. (No bugs found.)

user-sysmaint-split - consider disabling polkit-agent-helper-1[edit]

  • for potentially affected packages, see: "apt purge polkitd"
  • does it break Network Manager WiFi configuration from account "user"?
  • cat usr/lib/permission-hardener.d/20_user-sysmaint-split.conf
## TODO:
## See also:
## /usr/lib/permission-hardener.d/25_default_whitelist_policykit.conf
#/usr/lib/policykit-1/polkit-agent-helper-1 4750 root sysmaint
#/lib/policykit-1/polkit-agent-helper-1 4750 root sysmaint
  • Current verdict: I believe this is likely safe to disable.
    • Affected applications I tested were gparted, zulucrypt, and the NetworkManager widget.
    • NetworkManager "just works" even with this executable's permissions hardened.
    • gparted and zulucrypt are both broken for both user user and user sysmaint even without this executable's permissions hardened.
      • Note, gparted and zulucrypt probably *should* work in sysmaint mode. pkexec also doesn't work in sysmaint mode. I believe the reason they don't work is because there's likely a polkit-related systemd unit we need to be depending on in sysmaint-boot.target.
        • Patrick: follow-up ticket created
  • Patrick: disabled

live-build - enable GRUB force_efi_extra_removable[edit]

  • todo
  • if applicable
  • Already done in 2800_create-lb-iso. Shouldn't need any further changes to live-build to make work.

permission-hardener - disable action does not remove existing_mode and new_mode statoverride file[edit]

  • bug? as discussed.
    • Neither database should be removed wholesale.
    • existing_mode should keep tabs on any file permission-hardener touches, recording the original file modes as appropriate. It's fine for it to not be modified when disabling hardening on a file.
    • Removing entries from existing_mode is potentially dangerous since it can make it impossible for the user to disable permission hardening on a file if a bug is encountered that re-hardens the file after hardening has been disabled.
    • On my system, new_mode is appropriately modified when disabling one or all files. However, new_mode had some problems (it wasn't being copied forward to the new v2 location, thus rendering it useless, and the original file had some corruption issues), so I put a migration system in place for new_mode that is similar to the one we created for existing_mode.
    • https://github.com/ArrayBolt3/security-misc/tree/arraybolt3/more-permission-hardenerarchive.org

publish Debian security report[edit]

qubes-template-kicksecure[edit]

review list of remaining SUIDs[edit]

/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. - This is safe to disable. Chrome/Chromium now uses namespace-based sandboxing rather than a SUID sandbox for most use cases, and while the SUID sandbox is still technically supported (https://chromium.googlesource.com/chromium/src/+/0e94f26e8/docs/linux_sandboxing.mdarchive.org), it's also virtually unused (https://chromium.googlesource.com/chromium/src/+/0e94f26e8/docs/linux_suid_sandbox.mdarchive.org). Chromium still works fine when it is stripped of its SUID bit and rendered no longer executable, and opening `chrome://sandbox` while in this state shows that sandboxing is still working perfectly fine.

/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 this should be safe to disable.

/usr/lib/polkit-1/polkit-agent-helper-1: Should be handled in user-sysmaint-split? - Required for Polkit to function at all (https://polkit-devel.freedesktop.narkive.com/zXO4yEg7/documentation-on-polkit-agent-helper-1-and-suid#archive.org, https://gitlab.freedesktop.org/polkit/polkit/-/issues/168archive.org). Changing permissions here may break more than just normal privilege escalation. May be safe to disable for users other than sysmaint similar to what was done with pkexec and sudo, however even that might not be safe.

/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 this could require further review.)

/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/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.

  • Patrick: Migrated these comments to permission hardener configuration.
  • Patrick: Disabled SUID for chrome/chromium sandbox and SSH.

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

  • bug: when package user-sysmaint-split is removed, permission-hardener fails to restore sudo and pkexec permissions
  • Patrick:
    • Please move state file variable v2_state_file from inline to /usr/share/security-misc/permission-hardener-existing-mode-legacy-hardcoded or so. That would make that file more easily maintainable.
    • Please open a PR.

Instead of 

   echo "${v2_state_file}" > '/var/lib/permission-hardener-v2/existing_mode/statoverride'

Replace 

   cp '/usr/share/security-misc/permission-hardener-existing-mode-legacy-hardcoded' '/var/lib/permission-hardener-v2/existing_mode/statoverride'
    • Aaron: Done.
    • potential bug: Some files exist only in some situations. Legitimately.
      • '/usr/lib/permission-hardener.d/30_ping.conf' is Whonix-only.
        • Aaron: Not a problem, the existing_state for the ping executable is the same on Kicksecure and Whonix, regardless of whether anon-apps-config is installed or not.
      • user-sysmaint-split may or may not be installed
        • Aaron: Also not a problem for similar reasons.
      • Please make sure these situations do not result in "custom configuration detected".
        • Aaron: Tested, behaves as intended now.
    • Please INFO echo any custom configuration file found.
      • Aaron: Done.
    • Please exclude new image builds from this migration code. If folder /var/lib/permission-hardener does not exist, there is no need for the migration code to run.
      • Aaron: Done, by checking for the existence of the old-style /var/lib/permission-hardener directory.
  • PR with all changes integrated: https://github.com/Kicksecure/security-misc/pull/295archive.org

user-sysmaint-split - shutdown action - #2[edit]

  • a systemd unit to lock the sysmaint account on shutdown
  • ExecStop cannot be used. Quote man page:
    • "Also note that the stop operation is always performed if the service started successfully, even if the processes in the service terminated on their own or were killed."
    • "Note that the commands specified in ExecStop= are only executed when the service started successfully first."
  • A separate, real shutdown systemd unit required. Please compare with some other shutdown related systemd units using shutdown.target.
  • Should lock unconditionally no matter what boot mode. That should be safe on shutdown.
  • https://github.com/ArrayBolt3/user-sysmaint-split/tree/arraybolt3/lock-sysmaint-on-shutdownarchive.org
    • Redone to avoid ExecStop and use a shutdown-time systemd unit instead. Also locks down unconditionally on shutdown.

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

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.
  • moved content here: Analyze PAM Stack

debian grub-pc with grub-efi co-installation issue bug report[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]

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

  • todo

Debian Installer Verification[edit]

  • after live-build review queue made progress maybe

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=91842"