ToDo for Developers

From Kicksecure
< Dev
Jump to navigation Jump to search

TODO

TODO DEV[edit]

live-build - local repository support[edit]

  • add support to build from local repository

live-build - add mmdebstrap support[edit]

ISO - port to live-build[edit]

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]

Kicksecure grub-theme[edit]

Whonix grub-theme[edit]

review and refactor meta packages[edit]

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]

Tor 0.4.8.9 broken in combination with vanguards[edit]

Implement live mode with 90overlayfs[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]

apparmor.d review[edit]

WAITING ON[edit]

kloak - add support for /dev/input/mice[edit]

  • VM has no /dev/input/mouseX
  • VM has only /dev/input/mice
  • kloak ignores /dev/input/mice.
  • (user reported using a Ubuntu 24.4 VM)
  • kloak only uses /dev/input/eventX devices by design, these are provided by the evdev driver and seem like they should always exist
  • Could not reproduce issue with QEMU using either Kicksecure or Lubuntu 24.04 - /dev/input/eventX devices for mouse always exist, as do individual /dev/input/mouse devices. Need to know what hypervisor was in use to test further

Patrick:

  • asked user about which VM. waiting for reply.

kloak - add Qubes support[edit]

Aaron:

kloak - Qubes support - consider using Qubes API for orchestration[edit]

kloak - Qubes support - implement kloak within qubes-gui-daemon[edit]

REVIEW PLEASE[edit]

ARCHIVED[edit]

keepassxc org.freedesktop.secrets Linux distribution compatibly feature request[edit]

research enclaive[edit]

research constellation[edit]

research Intel TDX[edit]

ISO - wrong bootloader entry[edit]

ISO - fallback boot loader broken[edit]

  • Similar to above.
  • Ultimately this is not something we can fix until the migration to live-build is done.
    • Debian Live doesn't install with a fallback bootloader enabled *at all* by default, only the Debian-specific path has a bootloader installed to it.
    • Ubuntu installs a special "fix the UEFI NVRAM vars" bootloader under \EFI\BOOT\BOOTX64.EFI but that's Ubuntu-specific it appears.
    • There is an option in Debian that allows always installing the GRUB bootloader to the fallback bootloader path in addition to the normal installation location (https://wiki.debian.org/UEFI#Force_grub-efi_installation_to_the_removable_media_patharchive.org). This option would work great for us, however it requires that grub-efi-amd64 be installed, which requires grub-pc to be uninstalled, which looks like it will probably cause issues on non-UEFI systems.
    • At this point we have to choose to have either slightly broken UEFI, or slightly broken BIOS, there is no middle ground until the live-build migration is complete. However, we may be able to tell Calamares to not install a fallback bootloader of its own anymore since this bootloader doesn't work at all.

ISO - calamares - logo size reduction[edit]

ISO - calamares - encrypt button bug[edit]

ISO - live-config - dist shellprocess_fixconkeys_part[edit]

  • Why is this required? Please report, fix this issue upstream in calamares, if possible. Otherwise, please add a comment to the file in live-config-dist so these files can be removed some day.
  • Reported upstream at https://github.com/calamares/calamares/issues/2383archive.org

research Secure Cloud Hardware[edit]

research AMD Infinity Guard[edit]

tirdad[edit]

tirdad - read history and old discussions[edit]

tirdad - functionality review[edit]

tirdad - backports compatibility[edit]

tirdad - fix code issues[edit]

tirdad - upstream to Linux[edit]

  • please discuss upstream
  • see if it is possible to send a pull request upstream

tirdad - compile time hardening flags review[edit]

  • Any compile time hardening flags that could be set?
  • Setting compile-time flags could be dangerous. Would recommend just sticking with the defaults in the kernel.

tirdad - lwn article review[edit]

  • https://lwn.net/Articles/455270/archive.org
  • something important to know there?
  • Using random 32-bit numbers from the kernel's RNG will avoid any potential security issues like the ones described here.

tirdad - development branch[edit]

  • Please create a development branch that comes with all your PRs merged.
  • This has been completed by Aaron in the rewrite branch.

boot issues debugging[edit]

research AMD TSME[edit]

investigate locale issue[edit]

tirdad[edit]

security review tirdad.c[edit]

hardware security features for RamCrypt[edit]

  • If software-only isn't possible, maybe hardware features such as SGX need to be used.
    • SGX itself does not appear to be useful for us. It allows running security-sensitive code in a secure "box" that nothing else on the system can pry into, but that security-sensitive code is limited in capabilities. It does not appear to be possible to run an entire virtual machine in an SGX enclave.
    • Intel TXT and TME-MK are much better suited for our purposes.
  • todo research: Are there still unpatched security issues in SGX or similar features that could be used for that?
    • It appears known issues are patched in the latest processors. Microcode updates were used to fix some of the issues.

report GTK touchscreen detection bug[edit]

investigate kloak bugs[edit]

research Intel / AMD RAM Encryption[edit]

pKVM research[edit]

  • research if pKVM assumes a locked down host and/or remote attestation (Google SafetyNet)
  • Researched and added to Whonix Dev/cloud page

dracut follow-up[edit]

calamares luks encryption settings ticket[edit]

secure cloud research[edit]

  • move notes from chat to wiki
  • Revamped Confidential VMs section in wiki

RamCrypt + no-fill cache mode[edit]

  • Draft an email for the kernel development mailing list asking about the possibility of 100% RAM encryption, mounting CPU cache as RAM for the 3%.
Subject: Investigating practicality of full memory encryption techniques using frozen cache and TRESOR/RamCrypt

I am currently helping with software development for the Kicksecure and Whonix projects, which are heavily focused on privacy and security. One of the goals we'd like to achieve is making it possible to securely run virtual machines on x86_64-architecture cloud servers in a manner resistant to cold-boot attacks, without relying on technology such as Intel SGX and TDX or AMD SEV that requires trusting CPU-vendor-provided code, keys, etc.

The two main technologies we're looking into for this purpose are TRESOR[1] and RamCrypt[2]. TRESOR is a full disk encryption mechanism that stores all disk encryption keys in CPU registers, such that the key is never[3] stored in RAM. If used on the hardware of a VM host, this would prevent a cold-boot attack from finding the disk encryption key. RamCrypt is a full memory encryption mechanism that uses the same technique as TRESOR to hide an encryption key inside the CPU, using it to transparently encrypt and decrypt the memory of running applications using memory paging techniques. Both of them have working proof-of-concept implementations described in the linked papers. Our hope is to eventually get fully functional, production-ready TRESOR and RamCrypt implementations created and upstreamed into the Linux kernel. For the avoidance of doubt, I am not the author of or a contributor to either TRESOR or RamCrypt.

One issue we have with RamCrypt is that it leaves part of a protected process's memory unencrypted in RAM as necessary. By default, up to four 4k pages of RAM are unencrypted at a time, with new pages being decrypted and older ones being encrypted transparently as needed. This has the serious disadvantage of making a cold-boot attack potentially successful, even if it is statistically unlikely to work. The chances of a successful attack against RamCrypt are non-negligible - the RamCrypt paper shows that a RamCrypt-protected nginx instance left a critical encryption key exposed in RAM 3% of the time in their test scenarios. This is worrying to us, and we're wondering if there is a way to prevent this from being a problem.

Our current hope is to use a cache-as-RAM technique (similar to what is described in the Frozen Cache[4] project) to potentially overcome this limitation. The idea, roughly speaking, is to ensure that protected process memory is only ever present in decrypted form in one of the CPU caches, and is prohibited from ever touching system RAM. When a page of memory is accessed that is encrypted, a previously decrypted page will be encrypted, written to system RAM, then an encrypted page will be decrypted into cache and used. Cache should be approximately as hard to access in a cold-boot attack as registers, thus this would allow a protected process to be immune to cold-boot attacks by never storing any sensitive data decrypted in RAM. It appears that no-fill cache mode could potentially be used for this purpose, though doing so without entirely destroying system performance seems like it would be tricky and probably require dedicating one or more CPU cores to running "protected" software with this modified caching mode.

The high-level end goal is to allow KVM-accelerated QEMU processes to be run encrypted via RamCrypt, with no unencrypted VM memory touching system RAM, and with the physical machine running TRESOR to protect the filesystem on which the VM virtual disks are stored. To begin with, though, it would be useful to know whether it's even possible with Linux's architecture to combine RamCrypt and no-fill cache mode to transparently encrypt a process's memory without exposing it decrypted in RAM. Some advice on how to go about implementing something along these lines would also be welcome, so that we can implement it in a way that is most likely to be accepted into the upstream kernel.

Thanks for taking the time to read this, and have a great day!

[1] https://faui1-files.cs.fau.de/filepool/projects/tresor/tresor.pdf
[2] https://faui1-files.cs.fau.de/filepool/projects/ramcrypt/ramcrypt.pdf
[3] Well, almost never - the key is briefly stored in RAM when read from whatever device provides it, but it is immediately expunged from RAM thereafter.
[4] https://frozencache.blogspot.com/

ISO - Fix encryption checkbox bugs[edit]

ISO - calamares encryption settings[edit]

sudo cryptsetup --verbose --use-random --cipher aes-xts-plain64 --key-size 512 --hash sha512 --use-random luksFormat <device>

  • distribution developers should control most if not all of that line
  • "sudo" - is probably a given since cameras runs as root.
  • "cryptsetup" - maybe a distribution wants to use a wrapper.
  • "--verbose --use-random --cipher aes-xts-plain64 --key-size 512 --hash sha512 --use-random" these are certainly options which a distribution should be able to decide.
  • "luksFormat" -
  • "<device>" - probably provided by calamares through a variable

Based on theoretic considerations only. Since calamares uses a library to use cryptsetup (?) it may not be as simple for a distribution to set these command-line options?

Patrick:

Aaron:

org.freedesktop.secrets implementation[edit]

Cloud virtualization - research RAM-less encryption techniques for disk and RAM encryption[edit]

See https://www.whonix.org/wiki/Dev/cloud#Confidential_VMsarchive.org

live-build dracut test[edit]

ISO - error message during boot: mount: /sysroot: special device LiveOS_rootfs does not exist[edit]

unbootable system after installing dracut on a standard Debian installation[edit]

grub-live with 90overlayfs[edit]

## dracut support
## https://www.kicksecure.com/wiki/Grub-live#Developer_Information
##
## using Debian forked upstream module 90overlay-root (tested)
GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX rootovl"

Comment out. 

## using dracut upstream module 90overlayfs (untested)
#GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX rd.live.overlay.overlayfs=1 rd.live.overlay.readonly=1"

Comment in. Test. Fix if required. Report issues upstream to dracut.

If there are bookworm related issues, please test on trixie.

No backport required. The rationale of this task if to get away from Debian (fork) specific 90overlay-root to 90overlayfs one day. trixie is early enough since there are no major issues in the current implementation but might be in trixie if we don't port.

This works on Trixie - generate an initrd with the overlayfs module added, then boot with rd.live.overlay.overlayfs=1 on the kernel command line. The rd.live.overlay.readonly=1 parameter is unnecessary and should be removed - it's for systems where you have an immutable base filesystem and a persistent overlay, and you want to make the overlay read-only, putting another overlay on top of it.

This does not work on Bookworm - the overlayfs module script is simply not run despite being present. It's possible to drop to a rescue shell using rd.break=mount on the kernel command line, then run the script manually - this works, but is obviously not practical.

comment: Boot Existing, Usual Linux Installation from Hard Disk in Live Mode / read-only mode with dracut #1565archive.org

dracut - test dracut without systemd[edit]

kloak - memory leaks[edit]

  • chatgpt suggests...
    • struct entry in main loop might not be freed
    • n1 = malloc(sizeof(struct entry));
    • please check for other variables (specifically in main loop) which might not be freed
  • Double-checked just in case, this had been previously checked in my own ChatGPT code review and doesn't appear to be a problem. Entry items are created and stored temporarily in *n1, then queued. Those items are later assigned to the np variable and then freed in the event release loop (free(np)). The only edge case where I can see this going wrong is if kloak gets stuck and stops delivering events, which would also freeze the keyboard and make the user very likely to immediately termiante kloak.
  • The other variable which ChatGPT warned me of is pfds, which is very clearly freed when the loop exits, needed throughout the loop's entire lifetime, and which will be automatically freed if the loop is terminated since terminating the loop terminates the whole program.

kloak - Qubes support - read and comment in Qubes kloak in dom0 ticket[edit]

ISO - must choose encrypt vs not encrypt. Empty default setting[edit]

kloak - update readme[edit]

kloak - fix debug symbols[edit]

W: kloak-dbgsym: debug-file-with-no-debug-symbols [usr/lib/debug/.build-id/3a/ae8c705abefbd590d2206221eea4c2abd90cf4.debug][edit]

N: 
N:   The binary is installed as a detached "debug symbols" ELF file, but it
N:   does not appear to have debug information associated with it.
N:   
N:   A common cause is not passing -g to GCC when compiling.
N:   
N:   Implementation detail: Lintian checks for the ".debug_line" and the
N:   ".debug_str" sections. If either of these are present, the binary is
N:   assumed to contain debug information.
N: 
N:   Please refer to Bug#668437 for details.
N: 
N:   Visibility: warning
N:   Show-Always: no
N:   Check: binaries/debug-symbols/detached
N: 
N:

read Dev bash wiki page[edit]

  • https://www.kicksecure.com/wiki/Dev/basharchive.org
  • might be already known, just in case
  • checked it, bookmarked it, some of the issues mentioned there were things I hadn't thought of before (like echo '-e' failing or security risks from failing to use -- to signal end of options)

haveged test suite passes even if only 1s are produced?[edit]

oomd[edit]

ISO - Install to system desktop icon: maximize window[edit]

gpg sign all your future git commits[edit]

add gpg key to your github[edit]

Add python3 dependency to mediawiki-shell package[edit]

  • Lintian error during build of Kicksecure ISO from derivative-maker commit 8fa4ba76: "E: mediawiki-shell: python3-script-but-no-python3-dep /usr/bin/python3 (does not satisfy python3:any | python3-minimal:any) [usr/bin/mw-urlencode]"

seccomp debugging documentation[edit]

copy notes on seecmop debugging from https://github.com/Whonix/kloak/pull/1archive.org to https://www.kicksecure.com/wiki/Seccomparchive.org

(so in the future when this is happening, we can link to the documentation so users get an idea how to debug and fix this)

just briefly similar to the pull request

autostart systemd user unit xdg-desktop-portal[edit]

kloak - add configuration option to disable rescue key[edit]

  • user reported that some hotkeys aren't functional due to kloak rescue key.
  • suggested solution, feature request: allow rescue key to be disabled thorough configuration
  • a command line option + systemd unit drop-in configuration file?
  • example systemd unit drop-in configuration: https://github.com/vmonaco/kloak/issues/75#issuecomment-2196543109archive.org

kloak - testing[edit]

kloak - document rescue key[edit]

kloak - makefile fix[edit]

  • Makefile should check if pkg-config exist because otherwise it fails with libevdev error?

kloak - verbose log sharing[edit]

Documentation is currently stating:

Warning: Privacy implications of log sharing are unknown!

Might verbose log reveal the typing fingerprint of the user?

kloak - mouse click obfuscation[edit]

kloak - xrdp support[edit]

kloak development[edit]

backlog - one day[edit]

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

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