ToDo for Developers

From Kicksecure
< Dev
Jump to navigation Jump to search

TODO

TODO DEV[edit]

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

user-sysmaint-split - Qubes support[edit]

  • sysmaint-panel is probably functional as is?
  • user-sysmaint-split - useful to install in Qubes for Kicksecure or Qubes-Whonix? Probably yes, due to sudo hardening.
  • Plan for Qubes?
    • No longer install qubes-core-agent-passwordless-root by default.
    • Install user-sysmaint-split by default in new templates.
    • Users could not really use account sysmaint due to missing X server. Instead, user needs to use a Qubes Root Console.
  • user documentation
  • suggestions for https://github.com/QubesOS/qubes-issues/issues/9519archive.org?

user-sysmaint-split - Wayland support[edit]

  • todo
  • ssdm support (because that is LXQt's default login manager)

grml-debootstrap - fix UEFI bootloader updates[edit]

calamares dual legacy + efi booting support[edit]

  • as discussed

investigate Debian Rolling[edit]

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

qubes-template-kicksecure[edit]

implement sudoless[edit]

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

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

default password[edit]

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

audio[edit]

audio generally[edit]

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

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

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

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

Kicksecure Firewall[edit]

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

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

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

Secure Mount Options for better Security Hardening[edit]

wipe video RAM[edit]

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

Tor 0.4.8.9 broken in combination with vanguards[edit]

VirtualBox serial console[edit]

KVM related[edit]

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

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

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

machine-id research[edit]

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

check out bubblejail[edit]

sandbox-app-launcher[edit]

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

automated test suite - cli version[edit]

  • todo: discuss

apparmor.d review[edit]

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

  • todo

improved server support[edit]

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

WAITING ON[edit]

calamares - investigate keyboard layout issue[edit]

trixie port - misc[edit]

trixie port - meta packages[edit]

review and test IPv6 support pull requests[edit]

  • https://forums.whonix.org/t/add-ipv6-support/19893archive.org
  • https://www.whonix.org/wiki/Dev/ipv6archive.org
  • 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/35621archive.org
      • 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/2archive.org.

calamares - make 3.3.12 available in Bookworm[edit]

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

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

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

ISO - memtest86+[edit]

error: bad shim signature

test SysRq keys under LXQt Wayland[edit]

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

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

ISO - changed files issues[edit]

(annoted) 

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

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

ISO - Finish Module Action Follow-Up[edit]

lightdm ssdm[edit]

iso - calamares - Argon2id[edit]

live-build - add mmdebstrap support[edit]

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

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

security-misc - investigate PAM[edit]

live-build - local repository support[edit]

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

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

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

REVIEW PLEASE[edit]

permission-hardener refactor[edit]

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

ARCHIVED[edit]

research verified boot and measured boot[edit]

Update #1:

Please review:

Considered:

How does android implement relock bootloader with user custom keys?

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

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

Concept improvements:

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

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

iso sysmaint mode - #2[edit]

review wiki - shadow and ssh[edit]

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

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

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

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

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

fix Secure Boot fallback bootloader problems[edit]

ISO - Debug chsh failure[edit]

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

ISO - use BUILD_INITRAMFS_PKGS[edit]

boot modes wiki page review[edit]

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

review USBGuard pull request[edit]

review ARP related network settings[edit]

document sysmaint warnings in wiki[edit]

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

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

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

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

investigate dracut-config-generic[edit]

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

investigate sudoless[edit]

user-sysmaint-split[edit]

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

admin-gui[edit]

VirtualBox unattended installation pass-through[edit]

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

investigate dracut-config-rescue[edit]

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

dummy-dependency purge feature[edit]

    dummy-dependency [remove|purge] pkgname

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

simple integrity check boot option[edit]

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

ISO - GRUB - cosmetic GRUB error message[edit]

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

recovery mode disabling[edit]

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

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

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

Kicksecure Live ISO 17.2.8.1 GNU/Linux

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

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

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

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

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

derivative-maker git tag following[edit]

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

investigate run0[edit]

grub-live debian control best practices[edit]

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

ISO - fwupd[edit]

ISO - GRUB unicode.pf2 error message[edit]

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

ISO - live-build - misc improvements[edit]

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

live-build downloads[edit]

  • investigate
  • Handled.

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

swap-file-creator improvements[edit]

ISO - consider installing by default on ISO[edit]

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

multi architecture support[edit]

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

older[edit]

Dev/todo/archived

backlog - one day[edit]

Qubes doas ticket[edit]

Qubes umask ticket[edit]

investigate porting from sudo to doas[edit]

doas - send pull requests to Qubes[edit]

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

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

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

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

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

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

  • todo
  • Superceded by sudoless mode, moved to backlog

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

bootloader password[edit]

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

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

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

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

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

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

str_replace utf-8 bug[edit]

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

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

Qubes graphical-session.target missing bug[edit]

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

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

mediawiki bot setup[edit]

rootless X11[edit]

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

power9 RAM encryption research[edit]

  • todo

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

dracut add support for undeclared CDLABEL[edit]

as discussed

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

  • low priority, move to backlog please

Footnotes[edit]

Your support makes
all the difference!

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

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