{{Header}}
{{title|title=
ToDo for Developers
}}
{{#seo:
|description=TODO
}}
{{devwiki}}
{{intro|
TODO
}}
= TODO DEV =
== user-sysmaint-split - account bob breaks upgrade ==
* todo
== privleap - start early before other systemd units such as sdwdate ==
* if sane, doable
* to avoid sdwdate and others needing to use systemd After=privleapd.service
== user-sysmaint-split - Qubes - Selective sudo Access ==
* implement [https://github.com/QubesOS/qubes-issues/issues/9512 Selective `sudo` Access Enabling in VMs Without `qubes-core-agent-passwordless-root` via `qvm-service`]
** Need Qubes OS R4.3 for this, not able to install it on primary dev rig yet, awaiting arrival of an (already ordered) external drive enclosure.
*** Patrick: R4.2 should be sufficient?
**** Aaron: New major features cannot be introduced into R4.2. Needs to be developed for R4.3.
** Relveant Qubes OS tickets:
*** https://github.com/QubesOS/qubes-issues/issues/5840
*** https://github.com/QubesOS/qubes-issues/issues/5852
*** https://github.com/QubesOS/qubes-issues/issues/5853
*** https://github.com/QubesOS/qubes-issues/issues/2695
*** https://github.com/QubesOS/qubes-issues/issues/9512
== user-sysmaint-split - Qubes - sysmaint boot features ==
* implement [https://github.com/QubesOS/qubes-issues/issues/9750 Polish support for booting qubes with custom kernel command line parameters]
* related: [https://github.com/QubesOS/qubes-issues/issues/2238 Debian template: disable newly (all) installed services by default]
** Does this obsolete selective sudo access? No, probably not.
* Wrote several iterations of a spec, updating with input from Marek for each iteration.
== user-sysmaint-split - consider using policy-rcd-declarative-deny-all or alike in sysmaint mode ==
* Would using policy-rcd-declarative-deny-all (or similar) be useful in sysmaint mode to avoid unneeded systemd units from starting in sysmaint mode?
* related: https://github.com/QubesOS/qubes-issues/issues/2238
== Kicksecure Qubes Template bugs ==
* https://forum.qubes-os.org/t/kicksecure-17-template/31893
* "There’s an unwanted package" - systemcheck should show that. Try "systemcheck --verbose". Otherwise, dunno what this is referring to.
* "systemcheck reports that the Kicksecure Repository is disabled when it is not." - Systemcheck would also show that. Could this be a bug from an earlier version where the repository was not enabled indeed?
== grml-debootstrap - downstream handling grub-cloud versus /etc/default/grub ==
* After/if https://github.com/grml/grml-debootstrap/pull/299 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 configuration file.
* 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 ==
* https://github.com/grml/grml-debootstrap/issues/258
* The following line is very difficult to follow.
# 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 ==
* todo
* if applicable
== GRUB - Debian packages grub-pc and grub-efi co-install-ability ==
* please submit a patch to Debian to make grub-pc and grub-efi co-installable
== GRUB - boot related enhancements ==
* Are there any other boot related enhancements outstanding? If so, please create tickets for these.
== investigate Debian Rolling ==
* 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.html had a very large amount of positive feedback compared to other proposals
**** See also DEP-10 (https://dep-team.pages.debian.net/deps/dep10/) which is somewhat orthogonal but related
*** 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/drk Very incomplete, nowhere near usable. Will keep developing this.
== kloak and kloak-alike documentation ==
* please improve [[Keystroke Deanonymization]], specifically mouse fingerprinting documentation
* Mouse event timings are obfuscated. Both, mouse clicks and mouse movements cause mouse events. But because there's lots of events, mouse events clog the queue pretty quickly and end up not as well obfuscated. This is a problem with both apps and is basically impossible to solve to the knowledge of the author.
* Mention, compare kloak and Qubes kloak-alike.
* goals:
** address "they can track your mouse movement and that’s one of the most accurate unique digital fingerprints that exist. So if they are tracking mouse movement which is a high probability then they know exactly who you are and Tor isn’t helping."
** give users a realistic risk description
** put a spotlight on remaining issues, point researchers to potential areas of future research
== default password ==
* rationale: virtual console based login attempts. An attacker could connect a keyboard to a server to login.
* review wiki: [[Default Passwords]]
* helper-scripts: add a tool that looks user accounts with empty passwords, if feasible
* GUI ISO: calamares.
** link to documentation
** choices:
*** default: none (user must choose)
*** passwordless
*** set a password
* CLI ISO: non-existent, therefore non-issue for now
* GUI VM images: A setup-wizard-dist popup should explain this.
* CLI: an INFO message after login if there are any unlocked passwordless accounts
== ISO - use variable flavor_meta_packages_to_install ==
* using already existing variable flavor_meta_packages_to_install would simplify modifications
== audio ==
=== audio generally ===
* https://forums.whonix.org/t/port-from-pulseaudio-to-pipewire-for-audio-support/16879/40
* please read, comment if something useful to share
=== VirtualBox Intel HD Audio and PipeWire Incompatibility / Audio broken after increasing ram to 5 GB / No sound after latest updates - PipeWire Bug? ===
* https://forums.whonix.org/t/virtualbox-intel-hd-audio-and-pipewire-incompatibility-audio-broken-after-increasing-ram-to-5-gb-no-sound-after-latest-updates-pipewire-bug/18211
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081965
* please investigate if doable with reasonable effort
* Tried switching between Pulseaudio and Pipewire on a booted VM, discovered I could "initialize" the speakers with Pulseaudio and then Pipewire would work thereafter
* Virtually certain this is an upstream bug, was able to reproduce with both Ubuntu 24.04 and Arch Linux.
* Suggest switching to AC97 audio (even Arch Linux defaults to this under Virtualbox).
* Need to investigate upstream code
* Could not get any meaningful hints from pipewire, wireplumber, and pipewire-pulse logs. Pulseaudio shows an "alsa woke us up to write new data to the device but there was actually nothing to write" error in its logs. At this point this is likely to be a bug in VirtualBox or the snd-hda-intel kernel driver.
== live-build - test lb config --dm-verity ==
* 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 ==
* TODO: Reduce packages in https://github.com/Whonix/qubes-whonix/blob/master/debian/control thanks to the improved Qubes support by kicksecure-meta-packages, if applicable.
** https://github.com/ArrayBolt3/qubes-whonix/tree/arraybolt3/kicksecure-qubes-merge
** https://github.com/ArrayBolt3/kicksecure-meta-packages/tree/arraybolt3/kicksecure-qubes-merge
* Patrick: merged, tested and reverted
* Gateway:
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 ==
* https://github.com/Kicksecure/security-misc/issues/187
* This is in preparation for the next task.
* Discussion on how best to do this posted at https://forums.kicksecure.com/t/splitting-security-misc-into-shared-desktop-and-server-packages/674
== Kicksecure Firewall ==
https://forums.kicksecure.com/t/kicksecure-firewall/378/10
== Meta Packages, Kicksecure, Whonix - Desktop versus Server ==
https://forums.kicksecure.com/t/meta-packages-kicksecure-desktop-versus-kicksecure-server/415
== Secure Mount Options for better Security Hardening ==
* review discussions, wiki
* comment
* improve the solutions research
* https://www.kicksecure.com/wiki/Dev/remount-secure
* https://www.kicksecure.com/wiki/Noexec
* https://forums.whonix.org/t/re-mount-home-and-other-with-noexec-and-nosuid-among-other-useful-mount-options-for-better-security/7707
* vm-config-dist chmod 777 on /mnt/shared conflicts with noexec
== wipe video RAM ==
* add wipe video RAM support to [[ram-wipe]]
* maybe based on https://wiki.archlinux.org/title/Swap_on_video_RAM
* maybe also based on https://github.com/divestedcg/Brace/blob/master/brace/etc/profile.d/brace-env-overrides.sh
# 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 ==
* https://gitlab.torproject.org/tpo/core/tor/-/issues/40892
* write a script to use git bisect to auto test which commit introduced this issue maybe based on https://forums.whonix.org/t/vanguards-additional-protections-for-tor-onion-services/8064/64
* if not done by upstream yet
* if doable with reasonable effort
== VirtualBox serial console ==
* {{CodeSelect|inline=true|code=
sudo apt install serial-console-enable
}}
* [[Recovery#Serial_Console|Serial Console]]
* causes bug (spam of journal)
* https://forums.whonix.org/t/serial-console-in-virtualbox/8021/13
* fixable? upstream bug report?
* would installation by default be sane or a security issue?
== KVM related ==
=== KVM - 3D Graphics Acceleration - SPICE - Testing - drm ===
* please test: https://www.whonix.org/wiki/KVM#3D_Graphics_Acceleration_-_Testing_-_drm
* please mention your configuration (still using SPICE), quote Patrick and report here: https://forums.whonix.org/t/how-to-enable-3d-acceleration-in-kvm/16501/22
* test if DRM (direct rendering manager) is enabled as per https://www.whonix.org/wiki/KVM#3D_Graphics_Acceleration_-_Testing_-_drm
* test performance as per https://www.whonix.org/wiki/KVM#3D_Graphics_Acceleration_-_Testing_-_Performance
=== KVM - 3D Graphics Acceleration - Performance Test - Display SDL ===
* https://forums.whonix.org/t/how-to-enable-3d-acceleration-in-kvm/16501/22
* test SDL
* test if DRM (direct rendering manager) is enabled as per https://www.whonix.org/wiki/KVM#3D_Graphics_Acceleration_-_Testing_-_drm
* test performance as per https://www.whonix.org/wiki/KVM#3D_Graphics_Acceleration_-_Testing_-_Performance
=== KVM - 3D Graphics Acceleration - Performance Test - Display GDK ===
* https://forums.whonix.org/t/how-to-enable-3d-acceleration-in-kvm/16501/22
* test GTK
* test if DRM (direct rendering manager) is enabled as per https://www.whonix.org/wiki/KVM#3D_Graphics_Acceleration_-_Testing_-_drm
* test performance as per https://www.whonix.org/wiki/KVM#3D_Graphics_Acceleration_-_Testing_-_Performance
=== KVM - verify AppArmor sVirt confinement operation ===
* https://forums.whonix.org/t/help-welcome-kvm-development-staying-the-course/166/593
=== KVM - use rootless ===
* https://forums.whonix.org/t/rootless-virtual-machines-with-kvm-and-qemu/20952
* port documentation (and XML files, if needed) to qemu:///session, if sane
* search Kicksecure; and Whonix wiki - using [[Special:ReplaceText]]
* re-check if sVirt is still functional
=== KVM - port to unix domain socket based internal networking for Whonix-Gateway to Whonix-Workstation connections ===
* https://forums.whonix.org/t/help-welcome-kvm-development-staying-the-course/166/594
* update documentation
** https://www.whonix.org/wiki/Multiple_Whonix-Workstation#How-to:_Use_more_than_One_Whonix-Workstation_-_Easy
** https://www.whonix.org/wiki/KVM#Creating_Multiple_Internal_Networks
** https://www.whonix.org/wiki/Multiple_Whonix-Gateway#KVM
== machine-id research ==
* in preparation for the next task
* please read prior discussions
* https://www.whonix.org/wiki/Protocol-Leak-Protection_and_Fingerprinting-Protection#Identifiers_Design_Goals
* https://forums.whonix.org/t/revisit-handling-of-var-lib-dbus-machine-id/18827
* https://forums.whonix.org/t/anonymize-etc-machine-id/7721
* https://gitlab.tails.boum.org/tails/tails/-/issues/7100
* 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 ==
* in preparation for the next two tasks
* https://forums.whonix.org/t/stackable-wrappers/7944
* https://github.com/Kicksecure/proposals/blob/master/634-stackable-wrappers.txt
* https://forums.whonix.org/t/write-draft-for-stackable-wrappers-on-debian-devel/18776
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822693
* review, comment, pull request where applicable
* draft and/or open a discussion on debian-devel
== check out bubblejail ==
* https://github.com/igo95862/bubblejail
* in preparation for next task
== sandbox-app-launcher ==
* [[sandbox-app-launcher]]
* review
* promising? worth bringing back to life, polishing?
* at odds with apparmor.d?
* better using bubblejail?
== automated test suite - cli version ==
* todo: discuss
== apparmor.d review ==
* https://github.com/roddhjav/apparmor.d
* https://forums.whonix.org/t/apparmor-d-full-set-of-apparmor-profiles-1500-profiles/17389
** review
* https://github.com/roddhjav/apparmor.d/issues?q=is%3Aissue+author%3Aadrelanos
** check ticket status
* lightweight security review
** conceivable or too much effort?
== improved server support ==
* documentation
** rebrand wiki CLI for server
* Linux account passwords?
* cloudinit?
* vm-config-dist versus autologin CLI vs GUI vs server
= WAITING ON =
== Qubes kloak-alike tickets ==
* please comment on https://github.com/QubesOS/qubes-issues/issues/1850 and other related tickets as sensible
** https://github.com/QubesOS/qubes-issues/issues/1850#issuecomment-2655357292
** https://github.com/QubesOS/qubes-issues/issues/8541#issuecomment-2655358902
** https://github.com/vmonaco/kloak/issues/74#issuecomment-2655362546
* What other steps are required to enable Qubes kloak-alike for Qubes-Whonix? Please create tickets.
** https://github.com/QubesOS/qubes-issues/issues/9771
== calamares dual legacy + efi booting support ==
* as discussed
* Draft PR opened at https://github.com/calamares/calamares/pull/2422, needs more work
* PR is close to done, requested preliminary review so I can make the hopefully final iteration.
== grml-debootstrap - fix UEFI bootloader updates ==
* https://github.com/grml/grml-debootstrap/issues/297
* please send a pull request upstream
** Pull request: https://github.com/grml/grml-debootstrap/pull/299
** 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/1
* related PR: https://github.com/grml/grml-debootstrap/pull/302
== privleap - post-review improvements ==
* https://github.com/ArrayBolt3/privleap/issues/1
* Discuss, implement as appropriate
== review safe-print ==
* https://github.com/Kicksecure/helper-scripts/pull/14
== review and test IPv6 support pull requests ==
* https://forums.whonix.org/t/add-ipv6-support/19893
* https://www.whonix.org/wiki/Dev/ipv6
* please review for Non-Qubes-Whonix, Qubes-Whonix
* goal: merge as much as doable/possible without breaking networking
* enabling IPv6 support in Qubes-Whonix might only be possible during release upgrade to trixie based and orchestration with Qubes
* Waiting for planned fixes to land in PRs.
* Update 1:
** Please recheck.
** Notes:
*** square brackets aren't supported in systemd: https://github.com/systemd/systemd/issues/35621
*** quote "The only issue is that VirtualBox only supports IPv6 if we switch to bridged interface, which exposes whonix gateway to the network. libvirt requires adding custom NAT rules for IPv6, which are only automatically managed for IPv4. If we want to add this, we'd need to add a static IP configuration and give the user instructions on how to add NAT rules on the host. So for now only Qubes will have direct support for IPv6 for outgoing transactions, without further instructions a user needs to do on the host."
* Can't get it working in VBox (even with bridged networking), libvirt (even with a custom network interface), or Qubes (apparent bug in Qubes R4.3 prevents me from making a new network-providing qube). See https://forum.qubes-os.org/t/qubes-4-3-cannot-create-a-new-appvm-that-provides-network-to-other-qubes/30906/2.
* Update 2:
** https://github.com/Whonix/whonix-gw-network-conf/pull/1#discussion_r1903385107
** https://github.com/Whonix/whonix-gw-network-conf/pull/1#discussion_r1903385335
** please direct questions, issues to Daniel (such as by adding these to https://www.whonix.org/wiki/Dev/ipv6 or commenting on a pull request)
== trixie port - misc ==
* waiting for trixie to get frozen and stable enough
* 1) SSH configurations
** move configuration snippets from [[SSH]] wiki page to security-misc [not completed at time of writing in end of 2024 but should be early next year]
** https://github.com/Kicksecure/legacy-dist/blob/master/usr/sbin/release-upgrade
*** add ominous message to release-upgrade script if SSH client or server is installed
*** point out in distribution morphing instructions
* 2) repository codename split project names
** update repository origin value as per https://www.kicksecure.com/wiki/Dev/APT#changed_its_'Origin'_value_from_'whonix'_to_'kicksecure'
** (revert the revert of https://github.com/Kicksecure/derivative-maker/commit/25f5c7e11afd23f58f40286be1fd9097c31a705e)
* 3) move pwchange from usability-misc to to helper-scripts
* 4) convert user-sysmaint-split and sysmaint-panel from "loose packages" to dependencies of the respective meta packages
** add ominous message to release-upgrade script
* 5) Check if /etc/grub.d/10_linux was updated in Debian. If so, update our fork in dist-base-files.
== trixie port - port to Wayland ==
* https://github.com/Kicksecure/kicksecure-meta-packages/pull/2
== trixie port - meta packages ==
* implement [[Dev/Metapackages]] when porting to trixie
== calamares - make 3.3.12 available in Bookworm ==
* 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 ==
* 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+ ==
error: bad shim signature
* Fixable?
* Apparently requires a security review: [https://github.com/rhboot/shim-review/issues/314 Meta: Signing memtest86+ v6.10]
* [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032375 memtest86+: fails to work with Secure Boot enabled]
* Asked about what contributions would allow this to move forward on the debian-efi mailing list: [https://lists.debian.org/debian-efi/2024/12/msg00021.html Memtest86+ Secure Boot signing]
== test SysRq keys under LXQt Wayland ==
* ensure SysRq+unraw, SysRq+k behave as expected in context of [[Login spoofing]]
* Has issues, wlroots bug reported at https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3930
== ISO - btrfs versus grub-live bug - real fix ==
* todo
* report bug upstream
* systemd bug report: https://github.com/systemd/systemd/issues/35540
* 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 ==
(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.
*** Please discuss upstream. Since there is already some sort of dm-verity support in upstream live-build (scripts/build/binary_dm-verity), upstream might be receiptive.
**** Feature request filed: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1089618
** /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.
*** See also: https://www.whonix.org/wiki/Protocol-Leak-Protection_and_Fingerprinting-Protection#Identifiers_Design_Goals
*** TODO: Discuss.
**** Proposal for fixing this made.
** /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?
*** Yes, please discuss upstream.
**** Feature request filed: https://github.com/calamares/calamares/issues/2409
** /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.
*** Yes, please.
**** Bug report made: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1089624
** /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 ==
* https://github.com/calamares/calamares/issues/2321
* please follow-up
* Followed up on Matrix, will follow up again soon on Github if I don't get a response.
* Was informed by Adriaan de Groot that the code is still unfinished, and also on his radar.
== lightdm ssdm ==
* bug report: https://forums.kicksecure.com/t/kicksecure-inside-lmde-5/46/11
* cause of bug could be in rads or security-misc
* Unable to reproduce bug, request for more information at https://forums.kicksecure.com/t/kicksecure-inside-lmde-5/46/13
* More information received, need to retry this one more time
* Tested, finally managed to partially reproduce. Issue appears to be in SDDM.
* Debugging complete, bug report with fix filed. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1089004
== live-build - add mmdebstrap support ==
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031932
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031929
* Merge request: https://salsa.debian.org/live-team/live-build/-/merge_requests/370
== live-build - use APT with error-on-any ==
* 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/371. New configuration option now used in my branch of live-build.
== security-misc - investigate PAM ==
* 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:
** https://github.com/linux-pam/linux-pam/issues/842
** https://github.com/sudo-project/sudo/issues/415
* 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 ==
* add https://www.supergrubdisk.org/wiki/Loopback.cfg 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/376
** 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 ==
* todo
* Bug filed at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1087470
* Note that the use of apt-get in the binary stage appears to be very baked into live-build's logic. It's pretty unlikely this will change.
= REVIEW PLEASE =
= ARCHIVED =
== user-sysmaint-split - remove dependency on lightdm ==
* lightdm is not installed on Qubes OS VMs and should not be installed.
* desktop VM users may prefer sddm, which we are attempting to support.
* Done: https://github.com/ArrayBolt3/sysmaint-panel
** Patrick: merged
== user-sysmaint-split - Qubes tb-updater - fix disposable VM support ==
* https://forums.whonix.org/t/latest-update-breaks-tor-browser-in-disposables/21183
* revert the reverts:
** cf995c1d666fe3142f368afb243bd8be5be30734
** 814438e9f8a68da3ae3545f028e3850cac91e474
*** Reverts reverted and root cause fixed in https://github.com/ArrayBolt3/tb-updater/tree/arraybolt3/sudoless-fix
**** Patrick: merged
== user-sysmaint-split - test sudoless upgrade-nonroot ==
* ensure sudoless upgrade-nonroot doesn't damage system if privleapd is restarted during installation
* if output at restart is confusing, consider how to make it less confusing if such a restart occurs
* Details of issues and ideas on how to resolve them shared in chat
* Reverted back to sudo-based upgrade-nonroot, only works under user sysmaint. Also fixed some other bugs. https://github.com/ArrayBolt3/usability-misc/tree/arraybolt3/misc-fixes
** Patrick: merged
* Other fixes made while working on this:
** dist-base-files (allow sysmaint to use privleap): https://github.com/ArrayBolt3/dist-base-files/tree/arraybolt3/sysmaint-privleap
** Patrick: merged
** privleap (fix install failure): https://github.com/ArrayBolt3/privleap
** Patrick: merged
** user-sysmaint-split (fix race condition that sometimes resulted in sysmaint login during normal boot): https://github.com/ArrayBolt3/user-sysmaint-split/tree/arraybolt3/race-fix
** Patrick: merged
== read 3mdeb RAM decay research ==
* https://blog.3mdeb.com/2025/2025-01-24-ram-data-decay-research-part2/
* [[Cold Boot Attack Defense]]
* [[Ram-wipe]]
* [[Dev/RAM Wipe]]
* Read, added notes to [[Cold Boot Attack Defense]].
== live-build - local repository support ==
* add support to build from local repository
* Merge request: https://salsa.debian.org/live-team/live-build/-/merge_requests/369
* Alternate implementation merged by rclobus, we're now using upstream's version in derivative-maker.
== user-sysmaint-split - Qubes - sysmaint-boot.target - upstream feature request ==
* What would need to happen to make sysmaint-boot.target available in Qubes? Please discuss with Qubes, open a Qubes ticket, if applicable.
* related Qubes ticket: [https://github.com/QubesOS/qubes-issues/issues/2238 Debian template: disable newly (all) installed services by default]
* Ticket filed for this specifically: https://github.com/QubesOS/qubes-issues/issues/9750
== privleap - add crash recovery ==
* 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:
** privleap: https://github.com/ArrayBolt3/privleap
** dist-base-files: https://github.com/ArrayBolt3/dist-base-files/tree/arraybolt3/privleap
*** Patrick: both merged
== user-sysmaint-split - privleap - use systemd notify ==
* 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 ==
* 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 ==
* 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 ==
* 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 ==
* Users might be confused by user-sysmaint-split and prefer using sudo and pkexec normally.
* Using sudo dummy-dependency --purge user-sysmaint-split from sysmaint mode is functional but inconvenient.
* Add option to boot menu that offers to remove user-sysmaint-split for the user, to revert back to "classic" privilege escalation.
* Implemented, required changes to user-sysmaint-split and sysmaint-panel.
** https://github.com/ArrayBolt3/user-sysmaint-split/tree/arraybolt3/uninstaller
*** Patrick: Merged.
** https://github.com/ArrayBolt3/sysmaint-panel
*** Patrick: Merged.
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"])
* Patrick: This will cause issues with meta packages removal? Better to use dummy-dependency --yes --purge user-sysmaint-split.
** Aaron: Agreed, done. https://github.com/ArrayBolt3/sysmaint-panel
* Patrick: Merged.
== user-sysmaint-split - privleap - add a trigger to reload privleap once its configuration folder changed ==
* this is to receive updated/fixed privleap configuration files once these have changed
* Done: https://github.com/ArrayBolt3/privleap
** Patrick: Merged.
== user-sysmaint-split - privleap - start privleap after installation ==
* if possible (to avoid issues after installation)
* Did as part of adding a trigger to privleap.
== user-sysmaint-split - privleap - sdwdate-gui - temp folder ==
echo "$QREXEC_REMOTE_DOMAIN $1" | tee /tmp/sdwdate-gui-tmp-status
* consider use of a more secure folder
** Agreed on /run/user/1000/sdwdate, new code is here: https://github.com/ArrayBolt3/sdwdate-gui/tree/arraybolt3/temp-file-move
* re-check python valid characters sanity test
** Rechecked and tested, appears to be correct. Add automated testing of invalid ASCII to privleap's test suite.
* Patrick: Merged.
== sync fork of live-build with upstream ==
* Some MRs made upstream have been reimplemented and the polished versions merged. Pull these changes into our fork and adjust derivative-maker accordingly.
** derivative-maker: https://github.com/ArrayBolt3/derivative-maker/tree/master
*** Patrick: Merged.
** live-build: https://salsa.debian.org/ArrayBolt3/live-build/-/tree/arraybolt3/lb-dracut?ref_type=heads
*** Patrick: Merged.
* Aaron: Both of these need re-merged, the fix I did for isomd5sum turned out to be a workaround for a configuration issue. Upstream helped me discover the real problem there.
** Patrick: Both merged.
== user-sysmaint-split - privleap - breaks Qubes gui ==
* 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 ==
* 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 ==
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'.
* Latest changes from https://github.com/ArrayBolt3/privleap should resolve this.
== user-sysmaint-split - privleap - setup-dist and anon-connection-wizard ==
* Patrick: in progress by Patrick
* port to privleap incomplete
* will cause the same issue as this: https://forums.whonix.org/t/getting-setup-dist-error-in-whonix-gateway/21162
* Whonix-Gateway CLI, no desktop. policykit may not be designed for this.
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 ==
* [[Dev/sudo]]
** Ready for review:
*** https://github.com/ArrayBolt3/setup-dist/tree/arraybolt3/sudoless-privleap
**** Patrick: Merged. (Didn't merge branch "sudoless".)
*** https://github.com/ArrayBolt3/setup-wizard-dist/tree/arraybolt3/fix-spacing
**** Patrick: Not merged. But used autopeop. Merged branch "sudoless" instead.
*** https://github.com/ArrayBolt3/systemcheck/tree/arraybolt3/sudoless-privleap
**** Patrick: Merged.
*** https://github.com/ArrayBolt3/sdwdate/tree/arraybolt3/privleap
**** Patrick: Merged.
*** https://github.com/ArrayBolt3/tb-starter/tree/arraybolt3/privleap
**** Patrick: Merged.
*** https://github.com/ArrayBolt3/tb-updater/tree/arraybolt3/privleap
**** Patrick: Merged.
** https://github.com/ArrayBolt3/anon-gw-anonymizer-config/tree/arraybolt3/privleap
*** Patrick: Merged.
** https://github.com/ArrayBolt3/whonix-base-files/tree/arraybolt3/user-sysmaint-split
*** Patrick: Merged.
** https://github.com/ArrayBolt3/anon-connection-wizard/tree/arraybolt3/privleap
*** Patrick: Merged.
** https://github.com/ArrayBolt3/helper-scripts/tree/arraybolt3/sudoless-privleap
*** Patrick: Merged.
** https://github.com/ArrayBolt3/tor-control-panel/tree/arraybolt3/privleap
*** Patrick: Merged.
** https://github.com/ArrayBolt3/sdwdate-gui/tree/arraybolt3/privleap
*** Patrick: Merged.
* Patrick: Please move to archived if everything got merged as expected.
** Aaron: Looks good.
== user-sysmaint-split - implement sudoless #2 ==
** 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:
'/usr/bin/pkexec'
Will cause issue https://forums.whonix.org/t/getting-setup-dist-error-in-whonix-gateway/21162 - 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: https://www.kicksecure.com/wiki/Sysmaint"
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 ==
* Bug: removing user-sysmaint-split from a machine causes autologin to break, user is presented with login screen on boot
* Possibly caused by user sysmaint autologin handling?
* Fixed, along with some other issues: https://github.com/ArrayBolt3/user-sysmaint-split/tree/arraybolt3/fix-passwordless-login
** Patrick: Merged.
== Strong Linux User Account Isolation wiki page - add Wayland considerations ==
* edit [[Dev/Strong_Linux_User_Account_Isolation|Strong Linux User Account Isolation]] and point out differences in X11 versus Wayland in applicable chapters
* For example, chapter [[Dev/Strong_Linux_User_Account_Isolation#Console_Login_Attacks|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 ==
* port upgrade-nonroot to privleap, if sane
* do not add Depends: privleap
* https://forums.kicksecure.com/t/upgrade-nonroot-privilege-escalation-issue/886
* Done in https://github.com/ArrayBolt3/usability-misc/tree/arraybolt3/privleap
** Patrick: Merged.
* Patrick: refactored upgrade-nonroot. Could the following if needed please be improved, moved to its dedicated wrapper script to avoid code duplication?
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
* Aaron: The version merged appears to have some bugs. Fixed version here: https://github.com/ArrayBolt3/usability-misc/tree/arraybolt3/privleap
** Patrick: Merged.
* Aaron: Also needs accompanying update in helper-scripts to fully fix, this also provides warnings if privleap isn't usable like shown above: https://github.com/ArrayBolt3/helper-scripts/tree/arraybolt3/sudoless-privleap
** Patrick: Merged.
== user-sysmaint-split - avoid /etc as pid file location ==
* 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 ==
* 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
## 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 ==
* ran into serious issues with icons in Thunar, see https://forum.xfce.org/viewtopic.php?id=18054
** Patrick: Could you please update the Xfce forum thread?
*** Thread updated and marked as solved.
* Should be fixed by this: https://github.com/ArrayBolt3/kicksecure-meta-packages/tree/arraybolt3/fix-thunar-icons-qubes
** Patrick: Merged.
== qubes-template-kicksecure - #3 ==
* 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/9573 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 ==
* https://github.com/Kicksecure/helper-scripts/pull/13
* https://github.com/Kicksecure/user-sysmaint-split/pull/1
* Reviews complete and PRs were merged.
== privleap - compare what privleap is doing versus sudo and doas regarding environment ==
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.1):
*** 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#ENVIRONMENT):
*** 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/. 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 ==
* 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 ==
* 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 ==
* 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/6c653e64da4959de2b53b72ec49835c01808204b 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 ==
* please implement, if needed
* already done, will use it where needed
== privleap ==
* todo
* Beta-quality code: https://github.com/ArrayBolt3/privleap
** Extensively tested, but still needs battle-tested in real-world use and tested by someone other than just me.
== user-sysmaint-split - enable user-sysmaint-split by default for Xfce version ==
* for GUI (Xfce) version only:
** Patrick: Done.
* and for VM images as "loose packages"
** Patrick: Done.
* not Whonix-Gateway
** Patrick: Done.
* ISO: TODO
** Done: https://github.com/ArrayBolt3/derivative-maker Tested, works
== user-sysmaint-split - refactor pkexec support ==
* in https://github.com/ArrayBolt3/user-sysmaint-split/tree/arraybolt3/polkit /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1 gets hardcoded, started by a script
** Is this a good mechanism?
** What would be the usual mechanism to start it when booting into normal mode? Let's suppose the answer is "a systemd unit". In this case, wouldn't it be less surprising, easier to understand, cleaner to use the name mechanism when booting into sysmaint mode?
** Please either use the same mechanism or add a comment why this specific mechanism has been selected.
** Please document.
*** This does have to use a different mechanism, which is now documented: https://github.com/ArrayBolt3/user-sysmaint-split/tree/arraybolt3/polkit
== user-sysmaint-split - sysmaint-boot.target should allow SSH ==
* todo
* https://github.com/ArrayBolt3/user-sysmaint-split/tree/arraybolt3/ssh
== permission-hardener v2 - add easy debug feature ==
* permission-hardener could use an easy debug feature. Once run, it collects relevant outputs from permission-hardener (print-policy, state files and anything else that may be required), prints them to stdout.
* would have been useful for the following bug report
* Diagnostics command added: https://github.com/ArrayBolt3/security-misc/tree/arraybolt3/permission-hardener-diag
== permission-hardener v2 - repetitive polkit-agent-helper-1 messages ==
* 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-fix Fully resolves symlinks, rejects hardlinks.
== user-sysmaint-split - research Qubes user to root isolation ==
* todo: read, comment if applicable
* https://qubes-os.org/doc/vm-sudo/
* https://www.qubes-os.org/doc/vm-sudo-implementation/
* https://github.com/QubesOS/qubes-issues/issues/8823
** https://github.com/QubesOS/qubes-issues/issues/8823#issuecomment-1953115546
*** has a small mention of /dev/xen
**** reported as bug: https://github.com/QubesOS/qubes-issues/issues/9717
* https://github.com/QubesOS/qubes-issues/issues/2695
* https://forum.qubes-os.org/t/passwordless-sudo-selinux-understanding-security-logic/22446
* Researched, discussed with Qubes OS devs. Put research and discussion results here: https://www.kicksecure.com/wiki/Dev/Qubes#Root_Privilege_Isolation_and_libxenvchan
== user-sysmaint-split - passwordless-root fixes ==
* /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
** TODO
** which package would be suitable for the bind-dirs snippet?
*** I don't see why helper-scripts itself is bad, we do similar things for systemcheck, legacy-dist, and sdwdate.
*** https://github.com/ArrayBolt3/helper-scripts/tree/arraybolt3/dummy-dependency-qubes
== security - upgrade comment ==
* please comment as discussed
* https://forums.kicksecure.com/t/upgrade-nonroot-privilege-escalation-issue/886/3
== continuous review ==
* before merging newer derivative-maker git tag, please [[Dev/git#Compare|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 ==
* 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)
* Can find be used?
** find has many pitfalls: https://mywiki.wooledge.org/UsingFind
** Especially when using readarray?
* Aaron I'm using dpkg -V specifically to find ''modified'' permission-hardener files. It does a similar job to debsums. However, right now I'm letting it scan all packages on the system, when it really only has to scan security-misc, anon-apps-config, and user-sysmaint-split.
** Commit fixing speed issues: https://github.com/ArrayBolt3/security-misc/commit/396372c1295e2a09d596f3e23fccc26794a26f05
** Note: Not tested yet.
* Patrick: modified_pkg_data_str might include:
+ modified_pkg_data_str='missing /usr/lib/permission-hardener.d/20_user-sysmaint-split.conf'
* Patrick: merged. Tested. Please review my changes on top. (Theoretic only.)
** Aaron: Reviewed, recommended changes at https://github.com/Kicksecure/security-misc/compare/master...ArrayBolt3:security-misc:master
*** Patrick: Merged.
== user-sysmaint-split - fix pkexec for sysmaint user ==
* 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.
* Fixed, turns out it was a missing user-side startup process. https://github.com/ArrayBolt3/user-sysmaint-split/tree/arraybolt3/polkit
** Patrick: Merged.
== user-sysmaint-split - Whonix documentation review ==
* please review https://www.whonix.org/wiki/Sysmaint
** Fixed some typographical errors, otherwise looks good to me.
== user-sysmaint-split - Qubes support ==
* 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 [[Root#Qubes_Root_Console|Qubes Root Console]].
*** Patrick: Done.
* Plan for Qubes-Whonix-Gateway?
** Keep [[unrestricted admin mode]] to be on par with Non-Qubes-Whonix-Gateway?
*** Patrick: Done.
* user documentation
** Patrick. Done: https://www.whonix.org/wiki/Sysmaint
* suggestions for [https://github.com/QubesOS/qubes-issues/issues/9519 create user `admin` by default and add user `admin` to group `sudo` by default]?
== legacy-dist - enable GRUB force_efi_extra_removable ==
debconf-set-selections <<< 'grub-efi-arm64 grub2/force_efi_extra_removable
* please add to https://github.com/Kicksecure/legacy-dist (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 ==
* packages in https://github.com/Whonix/qubes-whonix/blob/master/debian/control 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-qubes
** 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 ==
* 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 ==
* 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 ==
* 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-hardener
== publish Debian security report ==
* as discussed
* Published: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718225#115
== qubes-template-kicksecure ==
* https://github.com/QubesOS/qubes-issues/issues/9573
* try if https://github.com/Kicksecure/qubes-template-kicksecure can be built locally
* document on [[Dev/Qubes]] how to download, verify Qubes builder v'''2''' (or fix upstream documentation if that seems more feasible)
** https://github.com/QubesOS/qubes-builderv2/
* Documentation written and tested.
* Upstream PR at https://github.com/QubesOS/qubes-builderv2/pull/170, approved and merged.
** Patrick: Done.
* Fixes needed ('''DONE'''):
** Figure out why repository-dist isn't being called, environment variable seems to not be getting through
*** Fixed in qubes-builderv2 PR, also required fixes to the Kicksecure and Whonix templates.
**** https://github.com/ArrayBolt3/qubes-template-whonix
**** https://github.com/ArrayBolt3/qubes-template-kicksecure
***** Done. Both merged.
== review list of remaining SUIDs ==
/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.txt. 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.md), it's also virtually unused (https://chromium.googlesource.com/chromium/src/+/0e94f26e8/docs/linux_suid_sandbox.md). 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-keysign), 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#, https://gitlab.freedesktop.org/polkit/polkit/-/issues/168). 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.html) 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 ==
* bug: when package user-sysmaint-split is removed, permission-hardener fails to restore sudo and pkexec permissions
** Fix with migration alert: https://github.com/ArrayBolt3/security-misc/tree/arraybolt3/permission-hardener-migrate
** TODO: Need to actually write the documentation for this on the wiki!
* 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/295
== user-sysmaint-split - shutdown action - #2 ==
* 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-shutdown
** 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 ==
* Kicksecure DNS setting is currently "implicit" as per https://forums.kicksecure.com/t/dns-nameserver-10-139-1-1/858/15
* It however, should be "explicit".
* Until more secure settings are implemented (waiting for replies from unbound), a sane /etc/resolv.conf file needs to be created during the build process
* VM builds vs ISO builds
* Implemented in initializer-dist to make sure it works no matter how things leak: https://github.com/ArrayBolt3/initializer-dist/tree/arraybolt3/resolv-conf
** Patrick: Not compatible with Whonix, there /etc/resolv.conf is package managed.
*** Patrick: Implemented in derivative-maker help-steps/chroot-raw instead.
== analyze pam stack ==
* 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: [[Dev/Strong_Linux_User_Account_Isolation#Analyze_PAM_Stack|Analyze PAM Stack]]
== debian grub-pc with grub-efi co-installation issue bug report ==
* please check if one already exists, report a bug or feature request against Debian for grub-pc with grub-efi co-install-ability
* https://bugs-devel.debian.org/cgi-bin/bugreport.cgi?bug=904062
== user-sysmaint-split - review changes ==
* Patrick made some minor changes.
** Reviewed, looks good to me. Will test when adding the sysmaint account lock shutdown action.
== address Linux Installer review ==
* some review comments about Linux installer have been sent privately
* please address, if applicable
* root_cmd or another function should be used instead of sudo
** this is for the benefit of using end-of-options ("--")
* real_file="$(sudo realpath "${file}")"
** please do not hardcode sudo, use root_cmd
** is variable real_file actually used for anything?
* use shellcheck
* All problems fixed:
** https://github.com/ArrayBolt3/helper-scripts/tree/arraybolt3/root-cmd-improve
** https://github.com/ArrayBolt3/usability-misc/tree/arraybolt3/dist-installer-sysmaint-polish
== DNS - Kicksecure Default DNS Discussion ==
* https://www.kicksecure.com/wiki/DNS
* https://www.kicksecure.com/wiki/DNS_Security
* https://forums.kicksecure.com/t/dns-nameserver-10-139-1-1/858/15
* https://forums.whonix.org/t/default-dns-provider-discussion-for-kicksecure-not-whonix/16870
* https://forums.whonix.org/t/use-dnscrypt-by-default-in-kicksecure-not-whonix/8117
* please read, comment, edit as applicable
** Read, updated documentation and wrote a long comment suggesting next steps for implementing DNSSEC
== document ARP related sysctl changes ==
* please create a [[networking]] wiki page
* https://github.com/Kicksecure/security-misc/pull/288
* https://github.com/Kicksecure/security-misc/pull/289
* https://github.com/Kicksecure/security-misc/pull/290
* https://github.com/Kicksecure/security-misc/pull/291
* Created, also tested arp_ignore's effects on a common virtualization use case.
== permission-hardener - usrmerge ==
* assume usrmerge, make it a dependency
* simplify configuration (/bin no longer needed)
* Distribution morphing: document, if applicable
** No need to depend on usrmerge, Bookworm requires merged /usr
** No need to document for the same reason
** Fixed security-misc with no more /bin modifications: https://github.com/ArrayBolt3/security-misc/tree/arraybolt3/usrmerge
== user-sysmaint-split - rads integration ==
* 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-script
== permission-hardener refactor ==
* 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-refactor
* PR: https://github.com/Kicksecure/security-misc/pull/293
== user-admin-split - installer sysmaint support ==
* context: [[Linux]]
* wrap all commands in run_as_root versus run_as_user, if useful
* improve privilege escalation tool detection
* sudo -u user
* keep unrestricted admin mode / "normal" Linux distribution compatibility
** PR with the bulk of the changes: https://github.com/Kicksecure/usability-misc/pull/13
** Sudoers exception needed to make the above work in sysmaint mode: https://github.com/ArrayBolt3/user-sysmaint-split/tree/arraybolt3/dist-installer-sysmaint
== user-sysmaint-split - Wayland support ==
* 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-support
* Will be difficult to fully test until Kicksecure's Trixie port is underway
== calamares - investigate keyboard layout issue ==
* https://forums.kicksecure.com/t/problems-with-the-installation/836
* Asked user for more information, cannot reproduce.
* No response, archiving.
== report research results to purism ==
* as discussed
* Done.
== pam wheel - review ==
* please review Patrick's new pam wheel implementation
** Reviewed and tested, looks good and works as intended on my end.
== sysmaint-panel - Qubes support ==
* 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-sudo
** Patrick: not merged. implemented with a different implementation. follow-up ticket created.
== ISO - ARM64 build failing ==
./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
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 ==
* are we using Argon2id because it is a cryptsetup default?
* please follow-up if useful on these tickets
* https://github.com/calamares/calamares/issues/2127
* https://invent.kde.org/system/kpmcore/-/merge_requests/43
* We are currently using Argon2id, but only because it is the default in Debian's cryptsetup.
* Followed up at https://invent.kde.org/system/kpmcore/-/merge_requests/43#note_1084941. No follow up needed on the Calamares ticket, the choice of which version of LUKS to use is already configurable and there's a good reason for Calamares to not default to LUKS2 yet.
* Waiting on a response from the original MR creator. Will make an MR of my own if allowed or if the original author doesn't respond in a week or so.
* Original MR creator did not respond, filed my own MR: https://invent.kde.org/system/kpmcore/-/merge_requests/56
* Merged upstream.
== heads ticket ==
* https://github.com/linuxboot/heads/issues/1881
* https://mjg59.dreamwidth.org/70630.html
** Potentially useful for the remote use case scenario, not useful for the local scenario, will add to wiki
* content useful for [[Verified Boot]]?
** Added.
== user-sysmaint-split - ISO - sysmaint mode - #3 ==
* follow-up
** live-config-dist: https://github.com/ArrayBolt3/live-config-dist/tree/arraybolt3/sysmaint
*** Patrick: Not merged. Needs revision to be compatible with "traditional boot mode" when user-sysmaint-split is not installed -> copied to new ticket
**** Aaron: Fixed.
== research verified boot and measured boot ==
* https://www.kicksecure.com/wiki/Dev/About_Computer_(In)Security
* https://www.kicksecure.com/wiki/Hardware_Wallet_Security
* https://www.kicksecure.com/wiki/Verified_Boot
* https://www.kicksecure.com/wiki/Measured_boot
* review, watch, improve, keep notes
* in preparation for consultation with firmware developer
Update #1:
Please review:
* https://www.kicksecure.com/wiki/Verified_Boot#Boot_Block_versus_TPM
** Aaron: Reviewed, updated. Note, the TPM doesn't use XOR when extending PCR values, and banks don't really matter half so much as PCRs, based on my research.
* https://www.kicksecure.com/wiki/Verified_Boot#Boot_Block_Based_Attacks_Against_Measured_Boot
** Aaron: Reviewed, updated, but I'm not sure where the fake TPM comes into play so I'm not sure I correctly understood this.
* https://www.kicksecure.com/wiki/Verified_Boot#TPM_EK_-_Endorsement_Key
** Aaron: Reviewed, updated.
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-s
* [https://source.android.com/docs/security/features/verifiedboot/device-state#user-settable-root-of-trust Android: User-settable root of trust]
* [https://source.android.com/docs/security/features/verifiedboot/boot-flow Android: Boot Flow]
* [https://source.android.com/static/docs/security/images/verified-boot-flow.png Android: Figure 1. Verified boot flow.]
* 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/1881
* 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 ([[Miscellaneous_Threats_to_User_Freedom#Device_Attestation_such_as_SafetyNet|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/. 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 ==
* rationale: "advanced boot options" are useless (because there are no multiple kernel versions for new VM images or after ISO installation) and confusing for new users
* helper-script: invent a new script grub-cfg-remove-advanced-boot-options to edit /boot/grub/grub.cfg directly
* run_once:
** chroot-scripts
** calamares
* document this on the [[Grub]] wiki page
* Ended up going with a different solution that moves all of the advanced boot entries to the end of the list. Looks cleaner, all functionality is retained. Changes were made to the following packages:
** dist-base-files: https://github.com/ArrayBolt3/dist-base-files/tree/arraybolt3/grub-cfg
** grub-live: https://github.com/ArrayBolt3/grub-live/tree/arraybolt3/grub-cfg
** user-sysmaint-split: https://github.com/ArrayBolt3/user-sysmaint-split
== iso sysmaint mode - #2 ==
* as discussed
* Current state (WIP):
** live-config-dist changes for unrestricted admin mode, probably shouldn't be merged until Trixie: https://github.com/ArrayBolt3/live-config-dist/tree/arraybolt3/sysmaint
*** Patrick: merged
** user-sysmaint-split bugfix: https://github.com/ArrayBolt3/user-sysmaint-split
*** Patrick: merged
** sysmaint-panel Calamares support: https://github.com/ArrayBolt3/sysmaint-panel
*** Patrick: merged
** live-build changes to add sysmaint and unrestricted admin changes (PROBABLY SHOULD HAVE PUSHED THIS TO A DIFFERENT BRANCH, '''DO NOT MERGE'''): https://salsa.debian.org/ArrayBolt3/live-build/-/tree/arraybolt3/lb-dracut?ref_type=heads
*** Patrick: merged - should git revert 4f1f20bb6f86e6a8ff2ae3aed450d83eb726a55e? (resolved as discussed)
** derivative-maker changes to enable sysmaint and unrestricted admin changes, probably shouldn't be merged until Trixie: https://github.com/ArrayBolt3/derivative-maker/tree/arraybolt3/sysmaint
*** Patrick: merged - should I git revert 68a91cb9a00a5e9f00947e002e2642f3da14e800? (resolved as discussed)
*** Patrick: What is the significance of Trixie here?
**** Aaron: I had thought we wanted to wait until Trixie to enable user-sysmaint-split by default, however as we discussed we could enable it earlier.
* Next round of changes, all should be merge-ready:
** helper-scripts: https://github.com/ArrayBolt3/helper-scripts/tree/arraybolt3/sysmaint
** live-config-dist: https://github.com/ArrayBolt3/live-config-dist/tree/arraybolt3/sysmaint
** usability-misc: https://github.com/ArrayBolt3/usability-misc/tree/arraybolt3/sysmaint
** sysmaint-panel: https://github.com/ArrayBolt3/sysmaint-panel/commit/f8db224e179ca7b32cffe7c21d8a159ef3e5abc3
** security-misc: https://github.com/ArrayBolt3/security-misc/tree/arraybolt3/sysmaint
** user-sysmaint-split: https://github.com/ArrayBolt3/user-sysmaint-split
* Patrick: all merged
* Another batch of patches:
** user-sysmaint-split: https://github.com/ArrayBolt3/user-sysmaint-split
*** Patrick: merged
** kicksecure-base-files: https://github.com/ArrayBolt3/kicksecure-base-files/tree/arraybolt3/sysmaint
*** Patrick: needs revision as discussed
** grub-live: https://github.com/ArrayBolt3/grub-live/tree/arraybolt3/sysmaint
*** Patrick: same as above
** helper-scripts: https://github.com/ArrayBolt3/helper-scripts/tree/arraybolt3/sysmaint
*** Patrick: merged
** live-build: https://salsa.debian.org/ArrayBolt3/live-build/-/commit/8484b589775c9783d396a84babd3c6c4eb53b7c2
*** Patrick: merged
** live-config-dist: https://github.com/ArrayBolt3/live-config-dist/tree/arraybolt3/sysmaint
*** Patrick: not merged -> but broken: breaks unrestricted admin mode
* Patrick: TODO:
** use config-package-dev displace for /etc/grub.d/10-linux for generic GRUB_DISTRIBUTOR setting based on already existing marker files
*** Ended up not doing this as it was avoidable and avoiding modifying 10_linux is probably a good idea for safety and maintainability reasons.
** live-config-dist: fix restricted admin mode
* Revised patches:
** live-config-dist: https://github.com/ArrayBolt3/live-config-dist/tree/arraybolt3/sysmaint
*** Patrick: Not merged. Needs revision to be compatible with "traditional boot mode" when user-sysmaint-split is not installed -> copied to new ticket
** user-sysmaint-split: https://github.com/ArrayBolt3/user-sysmaint-split
*** Patrick: Merged.
** grub-live: https://github.com/ArrayBolt3/grub-live/tree/arraybolt3/sysmaint
*** Patrick: Merged.
** kicksecure-base-files: none, patch deleted as it is no longer needed
== review wiki - shadow and ssh ==
* https://www.kicksecure.com/wiki/User#Meanings_of_Special_Characters_in_the_Password_Field_of_/etc/shadow_File
* https://www.kicksecure.com/wiki/SSH#SSH_Login_Comparison_Table
* Reviewed, added some info to both pages.
== sysmaint - no autologin if password is set - #2 ==
* 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-split
* 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-split
== live-config-dist- check-unrestricted-admin TMP folder ==
* /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 ==
* https://github.com/calamares/calamares/issues/2397
* PR here: https://github.com/calamares/calamares/pull/2400 Awaiting full review from devs.
* Reviewed and merged.
== fix Secure Boot fallback bootloader problems ==
* as discussed
* Fix part 1: https://github.com/ArrayBolt3/live-config-dist/tree/arraybolt3/secure-boot-fix
** Patrick: merged
* Fix part 2: https://github.com/ArrayBolt3/derivative-maker/commit/2ddc2dd7b8275cb440223c57a95305d8fb40cddc
** Patrick: merged
== ISO - Debug chsh failure ==
/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.
* Possibly caused by this commit? https://github.com/Kicksecure/dist-base-files/commit/e4ba4e8ffc43f5ec3326c742bf86d56c34f23d79
* We're trying to set the shell to zsh before the /etc/shells file is updated. Setting zsh as a Pre-Depends of dist-base-files silently failed to resolve this, thus had to be added to Kicksecure's package list at the appropriate location.
* Fixed: https://github.com/ArrayBolt3/derivative-maker/commit/ce6e8e5da6b3428eb36b1f7650edfab54436e5d2
** Patrick: merged
== ISO - use BUILD_INITRAMFS_PKGS ==
* todo: could you please use $BUILD_INITRAMFS_PKGS (already existing variable) instead of hardcoding dracut as initramfs generator?
* Done: https://github.com/ArrayBolt3/derivative-maker/tree/master
** Patrick: merged
== boot modes wiki page review ==
* [[Dev/user-sysmaint-split]] has been updated
* Please review.
* Ideas for chapter [[Dev/user-sysmaint-split#Server_Support|Server Support]], and
* chapter [[Dev/user-sysmaint-split#Todo|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 ==
* https://github.com/Kicksecure/security-misc/pull/166
* https://usb-ids.gowdy.us/read/UC/
* Reviewed PR, requested changes, did some simple tests to make sure it didn't cause major issues.
== review ARP related network settings ==
* https://github.com/Kicksecure/security-misc/pull/279
* Reviewed, can document if desirable
== document sysmaint warnings in wiki ==
* 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 ==
* 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"])
* Is /bin/sh needed? /usr/libexec/helper-scripts/terminal-wrapper "$SHELL" works for me (manually tested).
* https://github.com/Kicksecure/sysmaint-panel/blob/master/etc/X11/Xsession.d/15_no_sysmaint_xfce
** remove xfce from the name, if applicable
** move to user-sysmaint-split
* sysmaint-panel Depends: usability-misc or is that a superfluous dependency?
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-session
** 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
* add a sysmaint-panel /usr/share/desktop/sysmaint-panel.desktop file
* check file help-steps/pre function root_check
** something similar is required for sysmaint-panel
** if sudo cannot be executed -> show an error message, explain to boot into sysmaint, show a link
* sysmaint-panel: honor signal sigterm
* https://github.com/ArrayBolt3/sysmaint-panel
** Patrick: merged
* https://github.com/ArrayBolt3/user-sysmaint-split
** Patrick: merged
* https://github.com/ArrayBolt3/security-misc/tree/arraybolt3/sysmaint
** Patrick: merged
== investigate dracut-config-generic ==
* 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 ==
* https://github.com/secureblue/secureblue/releases/tag/v4.2.0
* https://www.kicksecure.com/wiki/Dev/secureblue#sudoless
* Could we go sudoless by default?
* sudo no longer readable/executable by user user should be equally good or better as sudoless? sudo SUID issues would not be a problem if user user cannot execute sudo anymore? Only user admin would be allowed to execute sudo.
* In case going "sudoless" (actually similar to sudoless), it would not even be required to port to either run0 or doas?
* This would require finding solutions for existing sudoers.d exceptions. This is can be drafted on the [[Dev/sudo]] wiki page.
* Sudoless desktop-config-dist: https://github.com/ArrayBolt3/desktop-config-dist/tree/arraybolt3/sudoless Ready for merge whenever desirable.
** Patrick: Was merged.
* '''WIP''' Persistent admin mode (EDIT: this is now bitrotten and is not the direction we're going in to implement this):
** Currently missing separate user account support!
** grub-live: https://github.com/ArrayBolt3/grub-live/tree/arraybolt3/sudoless Adds an admin mode boot entry.
*** This may be the wrong package to put this in, do we want a new package for this?
**** Patrick: grub configuration looks good but requires dedicated package.
** security-misc: https://github.com/ArrayBolt3/security-misc/tree/arraybolt3/sudoless Actually implements the permissions changes for user and admin modes.
*** Patrick: Does not really? Does not belong into security-misc. Dedicated package required.
== user-sysmaint-split ==
* implement package user-sysmaint-split as per [[Dev/user-sysmaint-split]]
* Control panel app for sysmaint mode: https://github.com/ArrayBolt3/sysmaint-panel
* Updated user-sysmaint-split with fixes, integrates with control panel app: https://github.com/ArrayBolt3/user-sysmaint-split
* sysmaint user account lock detection: https://github.com/ArrayBolt3/security-misc/tree/arraybolt3/sysmaint
* terminal-wrapper fix for better UX: https://github.com/ArrayBolt3/helper-scripts/tree/arraybolt3/terminal-wrapper
== pam-info improvements for user-sysmaint-split ==
* todo
* Done: https://github.com/ArrayBolt3/security-misc/tree/arraybolt3/sysmaint
== admin-gui ==
* open terminals - helper-scripts /usr/libexec/helper-scripts/terminal-wrapper
* update software
* reboot
* shut down
* Done: https://github.com/ArrayBolt3/sysmaint-panel
== VirtualBox unattended installation pass-through ==
* 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 ==
* https://forums.whonix.org/t/replacing-initramfs-tools-with-dracut/4487/8
* https://packages.debian.org/bookworm/dracut-config-rescue
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/724?
* 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/Dracut), 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 ==
dummy-dependency [remove|purge] pkgname
* Done: https://github.com/ArrayBolt3/helper-scripts/tree/arraybolt3/dummy-dependency-purge
== dracut rescue shell disablement maybe broken - VirtualBox install unattended option result in dracut rescue shell ==
* todo
* Fixed: https://salsa.debian.org/ArrayBolt3/live-build/-/tree/arraybolt3/lb-dracut?ref_type=heads The ISO will no longer be detected as an autoinstallable Debian ISO any longer after merging this.
== simple integrity check boot option ==
* not hidden under utilities
* simple hash check
* probably an existing dracut feature
* At ISO build time, a utility implantisomd5 (from the package isomd5sum) must be run on the built ISO to embed the md5 sum into it.
* Passing the kernel command line argument rd.live.check will trigger Dracut to run isomd5check to check the ISO's contents against this embedded md5 sum at boot time.
* Could add this to derivative-maker or live-build. Willing to implement wherever is preferred.
* Patrick (from chat): best upstream
* Upstream MR: https://salsa.debian.org/live-team/live-build/-/merge_requests/392
* live-build fork with enhancements: https://salsa.debian.org/ArrayBolt3/live-build/-/tree/arraybolt3/lb-dracut?ref_type=heads
* derivative-maker change to enable the feature: https://github.com/ArrayBolt3/derivative-maker/tree/master
== ISO - GRUB - failing to boot after installation ==
* version 17.2.8.2
* environment VirtualBox, EFI, Secure Boot
* ISO is booting
* after installation, does not boot
* Secure Boot issue: functional after disabling Secure Boot
* Fixed: https://github.com/ArrayBolt3/derivative-maker/tree/master
== ISO - GRUB - cosmetic GRUB error message ==
* 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 ==
* https://forums.kicksecure.com/t/harden-dracut-initramfs-generator-by-disabling-recovery-console/724
* https://forums.kicksecure.com/t/remove-linux-recovery-mode-boot-option-from-default-grub-boot-menu/727
* Done, but bootloader password still needs implemented. https://github.com/ArrayBolt3/security-misc/tree/arraybolt3/no-recovery-mode
== ISO - GRUB boot menu - add timeout to live boot menu ==
* todo
* Done: https://github.com/ArrayBolt3/derivative-maker
* Requires live-build changes from https://salsa.debian.org/ArrayBolt3/live-build/-/tree/arraybolt3/lb-dracut?ref_type=heads for all changes to work.
== ISO - GRUB boot menu - utilities option does nothing ==
* tested where: inside Qubes OS VM
* is memtest missing on the ISO?
** Yes, it is. Adding it should fix this issue.
* Done: https://github.com/ArrayBolt3/derivative-maker
* Requires live-build changes from https://salsa.debian.org/ArrayBolt3/live-build/-/tree/arraybolt3/lb-dracut?ref_type=heads for all changes to work.
* note: increase RAM in Qubes VM to avoid dropping to CLI (no GUI). Full instructions are here: [[Qubes#ISO|Qubes, ISO]]
== ISO - GRUB boot options text - add version number ==
Kicksecure Live ISO 17.2.8.1 GNU/Linux
${dist_build_type_short_pretty} Live ISO ${dist_build_version} GNU/Linux
* remove: built
* remove: linux
* remove: live-build
* remove: live-config
* possible to use live-build-data/grub-config/splash.svg as a template, copy it to temporary folder (as usual? derivative-binary?) and adjust?
* reason: dist_build_version is the most important if user post screenshots with this. everything else adds confusion?
* Done: https://github.com/ArrayBolt3/derivative-maker
* Requires live-build changes from https://salsa.debian.org/ArrayBolt3/live-build/-/tree/arraybolt3/lb-dracut?ref_type=heads for all changes to work.
== ISO - GRUB boot menu cosmetic efi related error messages ==
* 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 ==
* 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 ==
* 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/#u
* Found PatchViewer tool and documented use under [[Dev/git]]
== investigate run0 ==
* https://forums.whonix.org/t/replace-sudo-with-doas/17482/28
* https://www.freedesktop.org/software/systemd/man/256/run0.html
* as alternative to doas
* does run0 abolish the need for [[Dev/user-sysmaint-split]]?
** It does not, in fact its presence may make implementing the user/admin split difficult since it means systemd is providing a "backdoor" for running programs as root even without SUID bits being used.
*** Can be disabled using polkit config, change all auth options to no in the org.freedesktop.systemd1.manage-units section of /usr/share/polkit-1/actions/org.freedesktop.systemd1.policy
* Posted reasons to avoid use at https://forums.whonix.org/t/replace-sudo-with-doas/17482/29
== grub-live debian control best practices ==
* please review, improve
* https://github.com/Kicksecure/grub-live/blob/master/debian/control
* 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 ==
* Add fwupd
* fwupd-signed
* note: architecture specific? (As it turns out, yes.)
* Done: https://github.com/ArrayBolt3/derivative-maker/tree/master
== ISO - GRUB unicode.pf2 error message ==
error: `/grub2/fonts/unicode.pf2' not found
* Please fix.
* Should be fixed in latest derivative-maker improvements.
== ISO - live-build - misc improvements ==
* Any other misc improvements?
* live-config-dist: https://github.com/ArrayBolt3/live-config-dist/tree/arraybolt3/d-i-disable
* derivative-maker: https://github.com/ArrayBolt3/derivative-maker
== advice on safe_echo vs dist-installer-cli ==
* https://github.com/Kicksecure/usability-misc/blob/master/usr/bin/dist-installer-cli
* https://forums.whonix.org/t/whonix-linux-installer-development-discussion/15917/188
* Comment left, can work on implementing suggested fix if desired
== live-build downloads ==
* investigate
* Handled.
== review source code - str_replace file garbage bug - str_match ==
* already fixed in git master
* please review
** str_replace
** str_match
* Determined root cause - failing to truncate file when rewriting.
* Reviewed code, added minor improvements to reliability and performance: https://github.com/ArrayBolt3/helper-scripts/tree/arraybolt3/str_python_scripts
== swap-file-creator improvements ==
* https://forums.kicksecure.com/t/enhanced-heuristics-for-determining-the-swap-file-size-in-swap-file-creator/749/2
* swap-file-creator changes: https://github.com/ArrayBolt3/swap-file-creator/tree/arraybolt3/heuristics
* helper-scripts changes: https://github.com/ArrayBolt3/helper-scripts/tree/arraybolt3/heuristics
== ISO - consider installing by default on ISO ==
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 ==
* 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
* Better multi-arch support now at https://github.com/ArrayBolt3/derivative-maker/tree/master
* I tested amd64 and arm64 builds to reduce the risk of breaking things, but I did not test other architectures
== older ==
[[Dev/todo/archived]]
= backlog - one day =
== apt-get - implement --restrict-install-recommends proof of concept ==
* todo
== Debian Installer Verification ==
* after live-build review queue made progress maybe
== Qubes doas ticket ==
* feature request doas support for Qubes
* ask if Qubes would accept doas configuration snippets
* https://forums.whonix.org/t/replace-sudo-with-doas/17482/22
* Ticket filed as an enhancement request: https://github.com/QubesOS/qubes-issues/issues/9599
* Backlogged, we're going sudoless rather than porting to doas for now.
== Qubes umask ticket ==
* /etc/sudoers.d/umask
* https://forums.whonix.org/t/replace-sudo-with-doas/17482/22
* This was only needed if migrating to doas. Superceded by sudoless mode, moved to backlog
== investigate porting from sudo to doas ==
* https://forums.whonix.org/t/replace-sudo-with-doas/17482
* can our /etc/sudoers.d snippets be ported to doas? is doas powerful enough for our requirements based on our already existing /etc/sudoers.d snippets?
* could we have a system that no longer requires sudo or would we end up with a system that comes with both, sudo and doas? ("double" attack surface)
* use ReplaceText as a wiki search engine to find our current uses of sudo because these would need to be ported to doas
** https://www.kicksecure.com/wiki/Special:ReplaceText
** https://www.whonix.org/wiki/Special:ReplaceText
** search terms:
** sudo
** lxsudo
* Ensure sudoers.d config files used in Kicksecure and Whonix on Qubes OS can be ported to doas
* Did an audit of all uses of sudo in kickseure and whonix codebases, and how difficult they should be to port to doas. Results: https://gist.github.com/ArrayBolt3/6699ec4c631fec28e1f4c0a2e657fcd7
* Superceded by sudoless mode, moved to backlog
== doas - send pull requests to Qubes ==
* [[Dev/todo#Qubes_doas_ticket|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 ==
* 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 ==
* todo
* Superceded by sudoless mode, moved to backlog
== doas - create /etc/doas.d configuration snippets ==
* add /etc/doas.d configuration snippets to the various packages needing these
* if possible, pending discussion in https://forums.whonix.org/t/replace-sudo-with-doas/17482/19 for review of sudoers.d snippets by upstream
* Superceded by sudoless mode, moved to backlog
== bootloader password ==
* https://forums.kicksecure.com/t/harden-grub-bootloader-using-bootloader-password/723
== vm-config-dist re-installs same version ==
* Why a freshly built ova image attempts to upgrade vm-config-dist, even though it is already the latest version?
* https://download.kicksecure.com/ova/17.2.7.8/
* please investigate
[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
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
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-package. 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 ==
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
main()
File "/usr/bin/str_replace", line 26, in main
file_data = source_fh.read()
^^^^^^^^^^^^^^^^
File "", 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 ==
* Which source code file does enable systemd graphical-session.target target on Debian?
* https://github.com/QubesOS/qubes-issues/issues/9576
* Patrick: msgcollector now starts the systemd unit from /etc/xdg/autostart, that is good enough.
== add date and time detection to archive.today frontend ==
* 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 ==
* no wiki mass editing required for now
* will be required for mediawiki mass editing
* https://www.kicksecure.com/wiki/Special:BotPasswords
* https://www.kicksecure.com/wiki/Special:BotPasswords/botname
* https://www.whonix.org/wiki/Special:BotPasswords
* https://www.whonix.org/wiki/Special:BotPasswords/botname
* note: replace botname with actual name of bot
== rootless X11 ==
* 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 ==
* todo
== auto-detect, prompt for potential root devices in case the root= device is misconfigured or missing ==
* https://github.com/dracutdevs/dracut/issues/2589
* if doable with reasonable effort please send a pull request to dracut-'''ng'''
* Pull request: https://github.com/dracut-ng/dracut-ng/pull/694
* update: as discussed, low priority if effort is too high
== dracut add support for undeclared CDLABEL ==
as discussed
== live-build - Retry button in derivative-maker doesn't work ==
* low priority, move to backlog please
= Footnotes =
{{Footer}}