{{Header}}
{{title|title=
ToDo for Developers (archived)
}}
{{#seo:
|description=Archived TODOs
}}
{{devwiki}}
{{intro|
Archived TODOs
}}
= ARCHIVED =
== move archived tasks to Dev/todo/archived ==
* move to [[Dev/todo/archived]]
== iso - calamares - key stretching ==
* please review [[Passwords#Key-Stretching|Key-Stretching]]
* opportunities to improve calamares encryption settings?
* Looks good to me, Kicksecure is already using this, but there's room to potentially help other distros set this if they want.
== tirdad - dkms amd64 to arm64 cross build bug ==
* Qubes (amd64) build VM
* bug: Somehow DKMS is using the chroot's host (Qubes VM) kernel headers instead of the chroot's kernel headers.
* might be related to live-build commit:
** 4a8b01df80a958b0fe83d2bf8958d9e2124cb71c
** but that build already included that commit
* tirdad doesn't work on arm64 sadly (requires Livepatch, but arm64 lacks Livepatch), thus has to be omitted from arm64 builds.
** Commit: https://github.com/ArrayBolt3/derivative-maker/commit/a58d65f7f83e93e23ae9f46ed979a083f1245808
== passwordless-root ==
* todo: review
* [[Root#passwordless-root|passwordless-root]]
* [https://github.com/Kicksecure/usability-misc/blob/master/usr/bin/passwordless-root /usr/bin/passwordless-root]
* Looks good to me. The actual admin/user split can be implemented at least to begin with very simply, by using a systemd unit that reads a kernel parameter and adjusts available user accounts and SUID bits accordingly.
== review /usr/bin/passwordless-root ==
* usability misc - /usr/bin/passwordless-root
* Assuming it's been tested and works, the code looks good, I don't see any security holes here.
== live-build - localrepos - permission issue ==
* related to above?
* Qubes (amd64) build VM
N: Download is performed unsandboxed as root as file '/root/localrepos/kicksecure/pool/main/a/apparmor-profile-hexchat/apparmor-profile-hexchat_5.1-1_all.deb' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
...
+ error 'ERROR: Live build chroot stage failed!'
* Not a problem, this is a normal message for apt to show when installing packages from a local repo.
== doas - submit a pwfeedback feature request ==
* todo
* Request sent via email, see https://marc.info/?l=openbsd-tech&m=173284374231855&w=2
* Rejected by upstream.
== doas - submit a /usr/local/etc/doas.d /etc/doas.d drop-in configuration feature request ==
* todo
* parse only configuration files ending with .conf (to avoid parsing editor backup files ending with "~", ".bak", ".dpkg-old" or similar)
* Request sent via email, see https://marc.info/?l=openbsd-tech&m=173284374231855&w=2
* Rejected by upstream, response to the suggestion was borderline hostile.
== live-build - test arm64 cross-build support ==
* as discussed
* Changes were required to derivative-maker to support cross-building and arm64 ISO builds, also had to fix a couple bugs in live-build to make things work.
** Live-build changes: https://salsa.debian.org/ArrayBolt3/live-build/-/tree/arraybolt3/lb-dracut?ref_type=heads
** derivative-maker changes: https://github.com/ArrayBolt3/derivative-maker/tree/master
*** Native arm64 builds have NOT yet been tested
== immutable /usr /etc without overlay ==
* Try to boot Kicksecure with read-only (immutable) /usr /etc.
* There should be no overlay. "Real" read-only. Not similar to live mode with non-persistent overlay.
* In case of issues, try with Debian, as there might be Kicksecure specific issues.
* This task is in preparation for [[Dev/boot_modes]].
** Kicksecure booted but failed to reach a graphical desktop environment. Console login was impossible because PAM faillock errors out when it can't write to the tally file.
** Debian booted but failed to reach a graphical desktop environment. Console login worked, but neither systemctl restart lightdm nor startx were able to reach a login screen or desktop environment.
== implement umask hardening ==
* as discussed
* PR: https://github.com/Kicksecure/security-misc/pull/282
== grep review harden pkexec ==
* please grep all source code for pkexec and review
* Checked, everything that hasn't been reviewed in other tasks looks safe.
== review and harden repository dist policykit polit policy file ==
/usr/lib/python3/dist-packages/repository_dist_wizard/repository_dist_wizard.py
command = ['pkexec', 'repository-dist', '--enable'] + repository
Ok?
* Checked, this doesn't look like a threat to me, except in situations where the system is already badly compromised. Shared the one possible scenario with Patrick.
== umask research ==
* please research, find solutions for umask
* this is in preparation of
* https://forums.whonix.org/t/change-default-umask/7416
* https://github.com/Kicksecure/security-misc/pull/18
* https://github.com/Kicksecure/security-misc/issues/185
pam_umask.so debug umask=027
run a script, if root, do nothing, otherwise set umask
[success=2 default=ignore] pam_succeed_if.so debug uid eq 0
[success=1 default=ignore] pam_succeed_if.so debug use_uid uid eq 0
replace with pam_exec?
* Research recorded at https://github.com/Kicksecure/security-misc/issues/185#issuecomment-2492614076, still discussing if this is something we want to do or not.
* Investigate how ssh opens a session and how to set umask there
** Answer: The default umask set by OpenSSH is whatever umask it is launched with but with world and group write permissions disabled (so newly created files don't end up world-writable or group-writable by accident). If the user is entering an interactive SSH session, a login shell is launched, otherwise the command the user specifies is run using the user's default shell and a -c argument. If we want to configure the umask for all commands, we will have to set it via a shell launch script that runs even on non-login shells (i.e. bashrc or zshrc). If only login shells need configured, a profile script should suffice. There does not appear to be a configuration setting in OpenSSH for setting a umask outside of these mechanisms, the umask override for disabling world write and group write bits is hardcoded.
== Protection_Against_Physical_Attacks wiki page revision ==
* please improve [[Protection_Against_Physical_Attacks]]
* Done, did not document advanced GRUB password configuration because it requires writing a grub.cfg file by hand, and that would be best documented elsewhere.
== installed ISO - fix localhost ==
After installing from the ISO using calamres:
[user ~]% setsid -- sudo -- /usr/bin/test -x /usr/bin/test
[user ~]% sudo: unable to resolve host localhost.localdomain: Name or service not known
This causes an issue with systemcheck.
/etc/hosts is empty. But should be same as on Kicksecure Xfce for VirtualBox. Where it is:
[user ~]% cat /etc/hosts
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
[user ~]% cat /etc/hostname
localhost
If this was to change, it would need to be changed in Kicksecure for VirtualBox (and KVM) too. Would need to be changed in derivative-maker.
Probably best to set ISO /etc/hostname and /etc/hosts to the same value as Kicksecure for VirtualBox (derivative-maker) or what would be the canonical name?
* Fixed. https://github.com/ArrayBolt3/derivative-maker/tree/arraybolt3/network-config Uses same values for /etc/hosts and /etc/hostname as for VirtualBox builds, these values originally came from grml-debootstrap and the $dist_build_hostname variable.
== review and harden our pkexec policykit polkit policy files ==
* review
* harden, if there is something to harden
./packages/kicksecure/anon-connection-wizard/usr/share/polkit-1/actions/com.kicksecure.anon-connection-wizard.policy
./packages/kicksecure/live-config-dist/usr/share/polkit-1/actions/com.kicksecure.install-host-calamares-wrapper.policy
* Reviewed, shared results with Patrick.
* update 1: Please fix.
* Fixes:
** anon-connection-wizard: https://github.com/ArrayBolt3/anon-connection-wizard/tree/arraybolt3/pkexec
** tor-control-panel: https://github.com/ArrayBolt3/tor-control-panel/tree/arraybolt3/pkexec (needed changes to remain compatible with anon-connection-wizard changes)
== FYI - systemcheck test ==
After each build, please do a test.
{{CodeSelect|code=
systemcheck --verbose
}}
This catches major issues such as localhost issue.
* Will keep that in mind, my last build after fixing the localhost issue seems to pass this check.
== investigate absence of sudo doas pkexec ==
* SUIDs are a security issue.
* How realistic would it be to implement all sudoers / pkexec exceptions using Linux capabilities, file permissions or similar?
* Long term goal should be to have no application running as root / no user reachable SUIDs.
* Maybe doas, pkexec should only be reachable from user admin.
* If too complex, might be far future work and meanwhile we'll go doas (+ pkexec).
* Looks very complex but potentially doable, see https://man7.org/linux/man-pages/man7/capabilities.7.html. However, some sort of privilege escalation framework will still be needed for running things such as apt and requiring a password for that purpose.
* Applications that depend on checking for a root UID can be "fooled" into thinking they have root but really only having a limited set of capabilities
* May interact poorly with Debian, experimentation will be needed to find out
* Limiting access to sudo or doas can be done without having to go into an all-capabilities environment, a systemd unit could be used to ensure that the SUID bits on those applications are absent in user mode and present in admin mode
* Probably better to start with doas, will likely hit less hurdles attempting that.
* After further research, this looks very difficult or impossible to do with Debian. The capabilities system does not provide substantial additional security when used alongside "legacy" (i.e. user account based) privilege management, and using it on its own requires both executable files and systemd unit configuration to be configured to use capabilities properly. Most of Debian's applications are probably not configured to work this way, so we would need to ship ''extensive'' permission modifications in permission-hardener, as well as replace many, many systemd units for things such as display managers, servers, or anything else that ran as a systemd system unit and needed privileges to do its job properly. This does not seem practical, therefore I would highly recommend we stick with porting to doas.
* I tried searching for distros that use capabilities in lieu of root access - Google was very unhelpful, and Perplexity.ai just told me there weren't any distros like that.
== review rads ==
* https://github.com/Kicksecure/rads
* [[RAM Adjusted Desktop Starter]]
* Issues, both minor:
** rads_minimum_ram is set to 480 in the config file with rationale given, but defaults to 500 in rads itself, which could be problematic
** rads_no_swtich_vt is typo'd both in the variable itself and in the config file
* Very unlikely to be the source of the distro morphing bug reported earlier, the user had a working display manager at that point and was observing auth failures in their logs.
* update, Patrick: fixed
== review and harden our /etc/sudoers.d snippets ==
* review
* harden, if there is something to harden
* Done, hardening code merged
== rewrite from perl to python ==
* todo
* After auditing, I don't believe most of our uses of Perl need to be replaced. str_replace and str_match seemed potentially important to port however.
** Rewritten versions of str_replace and str_match: https://github.com/ArrayBolt3/helper-scripts/tree/arraybolt3/perl-to-python
== python perl etc pitfalls ==
* please study https://www.qualys.com/2024/11/19/needrestart/needrestart.txt
* Studied. The first three vulnerabilities are not PERL-specific, only the last two (involving two-argument open()) were. Of particular interest was https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=88890543 which warned about the <> and open().
* Reproduced the poison NUL byte and two-argument open() issues mentioned by https://phrack.org/issues/55/7.html#article locally. They are still a problem, even today. Also discovered that the poison NUL byte issue is a known and documented weakness in Perl: https://cwe.mitre.org/data/definitions/626.html
* https://stackoverflow.com/questions/1011431/common-pitfalls-in-python has useful advice for Python.
== fix sudoers.d related issues ==
* todo
* Fixes:
** https://github.com/ArrayBolt3/sdwdate/tree/arraybolt3/sudoers
** https://github.com/ArrayBolt3/sdwdate-gui/tree/arraybolt3/sudoers
** https://github.com/ArrayBolt3/security-misc/tree/arraybolt3/sudoers
** https://github.com/ArrayBolt3/helper-scripts/tree/arraybolt3/sudoers
** https://github.com/ArrayBolt3/systemcheck/tree/arraybolt3/sudoers
** https://github.com/ArrayBolt3/tb-starter/tree/arraybolt3/sudoers
== research archivebox and alternatives ==
* installation source issue
** nice but optional, because might be unavailable: signed releases available? available from packages.debian.org?
*** A Docker image is available, but Docker has supposedly had severe security issues related to image verification in the past: https://titanous.com/posts/docker-insecurity
*** There's also a package available via pip but it seems to make signing of releases optional and GPG support is very limited, so just because the package is on PyPI doesn't mean it's signed.
*** No signed release visible on releases page.
* predictable links issue
** web.archive.org is nice because using our [https://github.com/Kicksecure/mediawiki-link-to-archive mediawiki-link-to-archive] MediaWiki extension, each link gets appended with an archive symbol linking to https://web.archive.org/archive/.
** investigate if archivebox (or alternative) has such a feature
** post a feature request if not
** if such a feature does not exist, then mass wiki editing will be required to append links to our self-hosted archivebox (or alternative)
*** wiki mass editing is best avoided. Either we would use a different self-hosted archival tool or perhaps contribute such a feature upstream, if feasible?
**** A URL-encoded URL can be passed as a search query, similar to how archive.today allows searching for archives of a site with https://archive.today/https://google.com. This takes a bit more effort due to the URL encoding being mandatory, but it is doable it appears.
**** Feature request for archive.org style links (originally filed by the primary ArchiveBox author, commented on by me): https://github.com/ArchiveBox/ArchiveBox/issues/1085
**** The feature already exists and is usable upstream: https://github.com/ArchiveBox/ArchiveBox/issues/1085#issuecomment-2487121890
* public archive issue
** Ideally, the archive would not be "our archive" but a public archive.
** That does not mean, that we want to host a public archivebox archive that anyone can use. That would unfortunately be problematic (disk space, legal issues).
** We're already offering various downloadable backups on the [[Offline Documentation]] wiki page (including rsync access).
** For archived links it would be good if these could be offered in a backup format available to the public. I.e. someone could use rsync and download all links that we archived.
** With archivebox that might be problematic because links might be unpredictable. Archivebox has a search function but it relies on server functionality, server database (?), which we probably cannot share as is.
*** Should we nuke admin credentials so we can share the database with the public for backup purposes?
**** ArchiveBox actually has explicit support for publishing an archive as a static website. See https://github.com/ArchiveBox/ArchiveBox/wiki/Publishing-Your-Archive. Assuming this doesn't save any sensitive data, this would be a pretty easy way of doing this.
* design:
** Keep archive box web interface accessible to admins and bots only. (security)
** Keep link archival accessible to admin and bots only. (legal)
** Keep archived links reading accessible to the public.
** After wiki backup (already existing on the server) using mediawiki-shell, have a script that can parse the wiki for new links and add them to archivebox.
*** Needs support for a list of domains to avoid archiving (since archiving might be broken).
*** Due to some links being offline, often, need to probably fail open if some links are not archiveable.
== live-build - permission lockdown still functional test ==
* https://www.kicksecure.com/wiki/Dev/Strong_Linux_User_Account_Isolation#access_rights_restrictions
* Kicksecure installations from post-live-build media and pre-live-build media behave the same way in this regard.
** Initial user account user has home directory /home/user with permissions 750 (read/write/execute for owner, read/execute for group, nothing for other)
** User account created with adduser with name user2 has home directory /home/user2 with permissions 700 (read/write/execute for owner, nothing for group, nothing for other)
** User account created with useradd with name user3 has no home directory. Created home directory manually with sudo mkdir /home/user3; sudo chown user3:user3 /home/user3, permissions on directory are 755. Installing a package thereafter (such as git) '''does not''' change the permissions on /home/user3 to something more secure, despite what the linked documentation implies.
** It's possible that permission lockdown is broken, however if so, it is not the result of live-build, assuming my tests were sufficient to diagnose this.
== apt-get - recommends can no longer get installed after installation with --no-install-recommends - bug report ==
`apt install --no-install-recommends diffoscope`
User story: Good, I did not want these recommends. And I didn't get these. Great. But... Now I noticed that i cannot figure it out or something and want these dependencies anyhow.
`apt install diffoscope`
* expected result: `Recommends:` get installed now
* actual result: not happening
`sudo apt satisfy diffoscope` or even `sudo apt install --install-recommends diffoscope` does not install the `Recommends:`.
The only way to get the dependency is `apt remove` followed by `apt install`.
* Turns out there is already a feature request for this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894976 Would be willing to try and implement.
* Patrick: now documented here: https://www.kicksecure.com/wiki/Install_Software#--no-install-recommends
== grub boot menu - regression - mini symbol stuck bug ==
* the Kicksecure lock (or in case of Whonix the hat symbol) on the left next to the first boot menu entry looks confusing. This is because when selecting a different boot menu entry, that symbol will stay where it is.
* simple solution: remove that symbol without replacement
* harder solution: when pressing arrow down, move the highlight (different color for selected boot menu entry) as well as the mini symbol
* Ended up going with the simple solution, because I didn't think the UX of the harder solution would make sense. In a multiboot scenario, having the Kicksecure icon show up next to an OS other than Kicksecure would potentially be weird.
* Modified branches:
** Kicksecure: https://github.com/ArrayBolt3/kicksecure-base-files/tree/arraybolt3/no-grub-theme-icon
** Whonix-Gateway: https://github.com/ArrayBolt3/anon-gw-base-files/tree/arraybolt3/no-grub-theme-icon
** Whonix-Workstation: https://github.com/ArrayBolt3/anon-ws-base-files/tree/arraybolt3/no-grub-theme-icon
** Note: I only tested the Kicksecure changes so far (they work fine on both BIOS and UEFI systems). The Whonix-Gateway and Whonix-Workstation changes are not tested, though they are functionally identical to the Kicksecure changes and as such should work.
== start discussion about Weak-Depends on debian-devel mailing list ==
* as discussed
* see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942303
* Discussion at https://lists.debian.org/debian-devel/2024/11/msg00018.html
* Discussion seems to have halted, the idea that seemed the most promising was allowing the user to specify what packages they wanted to install the recommends of, while leaving other packages out.
* Should a task be added for implementing a proof of concept for this?
== calamares - timezone issue ==
* https://forums.kicksecure.com/t/kicksecure-installation-cannot-set-timezone-link-creation-failed-target-usr-share-timezone-link-name-etc-localtime/652
* Could not reproduce, tried one UEFI "Erase disk" installation, one BIOS "Erase disk" installation, and one BIOS "Replace partition" installation. Forum comments at https://forums.kicksecure.com/t/kicksecure-installation-cannot-set-timezone-link-creation-failed-target-usr-share-timezone-link-name-etc-localtime/652/4
* Turned out to be the result of attempting to install Kicksecure onto a FAT32 partition.
== calamares - file system unit test ==
* possible to translate https://forums.kicksecure.com/t/kicksecure-installation-cannot-set-timezone-link-creation-failed-target-usr-share-timezone-link-name-etc-localtime/652/6 into a calamares unit test so it would show a better error message?
* Feature request made for allowing distros to deny certain filesystems from being used for certain mountpoints: https://github.com/calamares/calamares/issues/2397
* Should a task be added for implementing the functionality in this feature request?
== review kloak makefile pull request ==
* https://github.com/Whonix/kloak/pull/5
* Review complete, nothing malicious found, some quality and functionality issues were found for which I suggested several changes.
* All issues fixed, approved PR.
== live-build - mmdebstrap should use security.debian.org repository ==
* bug: Debian security repository is not being used.
* Using Debian security repository is however a security feature and reason why using mmdebstrap. To bootstrap from more than 1 repository (Debian "normal" + Debian security) repository.
* Issue should be resolved with the following changes:
** live-build changes: https://salsa.debian.org/ArrayBolt3/live-build/-/tree/arraybolt3/lb-dracut?ref_type=heads (same branch as before, Kicksecure's fork will need to be updated to match it)
** derivative-maker changes: https://github.com/ArrayBolt3/derivative-maker/tree/arraybolt3/mmdebstrap-enhance (this '''will''' break the ISO build if merged without updating live-build)
== salsa debian - salsa signing key setup ==
* https://salsa.debian.org/ArrayBolt3/live-build/-/commits/arraybolt3/lb-dracut?ref_type=heads
* please upload your gpg public key to salsa.debian.org, if that is acceptable.
* similar to github.com
* so we get "verified" marks everywhere
* Done.
== kloak - Qubes support - implement kloak within qubes-gui-daemon ==
* https://github.com/QubesOS/qubes-issues/issues/8541#issuecomment-2377325699
* Ensure code is modular and can be easily broken out into a separate library or executable if requested by Qubes devs
* Use common code between standalone version and Qubes version to keep differences as small as possible (perhaps create libkloak?)
* Prototype implemented and mostly working, draft PR at https://github.com/QubesOS/qubes-gui-daemon/pull/149
* Waiting on response from Qubes OS devs
* Got response and review, currently working out final implementation and doing testing
* All code has now been merged.
== Implement live mode with 90overlayfs ==
* context: [[grub-live]]
* https://github.com/Kicksecure/grub-live
* https://github.com/Kicksecure/grub-live/blob/master/etc/grub.d/11_linux_live
* stop using 90overlay-root
* port grub-live to 90overlayfs
* This does not work in Bookworm, but does work in Trixie.
* Once Trixie is released and we're upgrading Kicksecure to it, switch modules. See https://github.com/dracutdevs/dracut/issues/1565#issuecomment-2378133277
** Since there is a source code comment pointing that out, mygrep -r TODO | grep trixie will find this task when it is due
== live-build - live_build_package_list_kicksecure - do not hardcode amd64 ==
* live-build-data/live-build-config/live_build_package_list_kicksecure
linux-image-amd64
linux-headers-amd64
* should be generic based on already existing variable ${dist_build_type_short}
* Fixed in https://github.com/ArrayBolt3/derivative-maker/tree/arraybolt3/avoid-amd64-hardcode
== live-build bug - cannot create /dev/null: Permission denied ==
build machine:
* CI: passing
* using a Qubes Kicksecure based App Qube: broken
* /usr/bin/apt-key? Where in derivative-maker or live-build is /usr/bin/apt-key being used anyhow?
** apt update is calling it. Verified by chrooting into the broken live-build chroot and running sudo apt update.
* Note: apt-key is deprecated as per apt-key Debian upstream man page anyhow and should not be used.
** Since this is apt itself using it, I think this is working as intended.
* Root cause of the problem: /home is mounted with nodev inside Kicksecure Qubes. This results in the chroot's /dev/null being unwritable even by root.
* Should be fixed here: https://github.com/ArrayBolt3/derivative-maker/tree/arraybolt3/home-nodev-fix Remounts /home with the dev option to resolve the problem.
== uwt torsocks TORSOCKS_LOG_LEVEL ==
* check if package uwt /etc/sudoers.d/uwt is still required
* https://forums.whonix.org/t/disable-torsocks-warning-spam/19084
* if still an issue, please send a pull request to upstream making TORSOCKS_LOG_LEVEL configurable in /etc/tor/torsocks.conf
* This does not appear to be an issue any longer. I commented out all `TORSOCKS_LOG_LEVEL` setting lines in `uwt.sh`, `uwtwrapper`, and `/etc/sudoers.d/uwt`, and saw no log messages similar to that in the logs. I also did export TORSOCKS_LOG_LEVEL=5; sudo -E torsocks apt-get.anondist update, and while this produced lots of debugging messages from torsocks due to the high verbosity level it was set to, none of those messages were the offending message from the linked bug report. With any lower loglevel, torsocks was silent.
== url_to_unixtime review and hardening ==
* https://github.com/Kicksecure/sdwdate/blob/master/usr/bin/url_to_unixtime
* (mostly) out of scope? validation of command line inputs
* out of scope: timeout - this is enforced on sdwdate level and does not need to be implemented at the url_to_unixtime level
* todo: check if minimum + maximum string lengths are properly enforced
* already has a dedicated AppArmor profile:
** https://github.com/Kicksecure/sdwdate/blob/master/etc/apparmor.d/usr.bin.url_to_unixtime
** https://github.com/Kicksecure/sdwdate/blob/master/etc/apparmor.d/abstractions/url_to_unixtime
* threat model:
** remote code execution
** outputting too short/long/non-numeric strings or malicious binary data that could confuse/exploit sdwdate
* Issues found:
** request_data_from_remote_server: The remote_port argument is never used in this function (or anywhere in the script). There doesn't appear to be an immediately obvious way to even use an argument like this with Requests.
** data_to_http_time does not enforce a maximum number of characters in the http_time string. This means that even an extremely long string will be parsed as a date later on in http_time_to_parsed_unixtime, which could theoretically be used to consume resources on a machine under attack.
** Multiple locations in the code will print to stderr values that may be bad in one way or another (most notably, every single HTTP header the script gets from the server will be printed in many instances) in the event of an error condition. The code specifically notes that it "prints debug and errors to stderr", thus I do not believe this is a serious concern. I didn't see any substantial processing happening on stderr elsewhere in sdwdate except to ensure it wasn't excessively large and to print it to stdout, which I believe ends up in the journalctl logs.
** unixtime_sanity_check doesn't ensure that the timestamp it returns is non-negative.
** The socks module is being imported for no reason. requests does not require it to be imported to access Tor over a socks5 proxy.
** Some miscellaneous unused variables, unneeded parentheses, and typos are floating around according to PyCharm.
* Other than that, it seems good:
** minimum date string length is enforced in data_to_http_time
** maximum timestamp length is enforced in unixtime_sanity_check
** only a sufficiently short timestamp derived from a sufficiently long date string will be printed to stdout (only a single print command is used for that purpose, and it only prints a variable that has passed all checks)
** I don't see any RCE risk aside from unknown and unknowable issues in the Python interpreter itself. The only bit of code that's really scary in this respect is when http_time_to_parsed_unixtime calls dateutil and trusts it to properly handle arbitrary, untrusted date headers from HTTP connections. dateutil is written entirely in Python though, so this isn't much of a threat - the worst that could happen is url_to_unixtime could crash, or return a garbage time value. (However, see the note about a lack of negative time prevention above.)
* sdwdate branch with all listed issues resolved: https://github.com/ArrayBolt3/sdwdate/tree/arraybolt3/url-to-unixtime-tidy
== tbb version parser hardening ==
* '''todo:''' discuss
* The local version parser function `tbbversion_installed` could be moved to /usr/bin/update-torbrowser for now as it is considered low risk.
* The remote version parser function `tbbversion` requires hardening:
** Out of scope: `tbbversion` taking too much time (can be easily handled from update-torbrowser by using standard Linux program timeout).
** Currently has good error handling, but errors have not been reported yet. We could give up on good error handling except for distinguishing between exit 0 (ok) and exit 1 (error).
** Needs to be written as securely as possible:
*** Attack surface currently includes at least: `jq`, `bash`, `/usr/libexec/msgcollector/striphtml`.
*** Remote version file cannot be verified (only through HTTPS or onion).
*** '''todo research:''' Will upstream provide signed version files? How does Tor Browser internally verify the version file? Can we use the same mechanism?
*** Version parser should be moved into its own standalone script.
*** Should it be rewritten in Python for better security?
*** The new version parser could be confined using AppArmor.
*** The version parser would either accept an input file and output file, with no other console output:
**** If the version parser gets exploited but is still contained by AppArmor, malicious advice could still be outputted to the console. Therefore, error codes should instead be communicated through exit codes:
***** Exit 1: General, not specifically handled/expected error.
***** Exit 2: Input file does not exist.
***** Exit 3: `jq` failed.
***** Etc.
*** String length sanity checking with if [ "$actual_string_length" -gt "$max_string_length" ]; then makes a lot of sense but should not be done within the version parser:
**** If `jq` is compromised, the string length check could be omitted. Therefore, string length checking should be handled externally.
**** Assumption: If string length is kept minimal, exploitation might be difficult or even impossible.
**** Version number is currently 14.0.2. Maximum string length is 20 characters. Since version numbers are short and reasonable, the maximum string length could be further reduced.
**** If the version parser is compromised, outputting evilevil instead of 14.0.2 might be insufficient to exploit update-torbrowser. However, allowing the parser to output a 10 MB file increases risk significantly.
**** A robust design could involve the version parser accepting an input file and generating an output file, with no console output allowed:
***** File-based input/output design allows update-torbrowser to safely check file size. If too large, it can be rejected as either a bug or an exploitation attempt.
**** Separation between version parser (AppArmor'ed) + file size checker (AppArmor'ed) + tb-updater might be overkill?
**** Should be placed into /usr/libexec/tb-updater?
** Should Tor Project and ARM64 version parsers be different?
* After discussion with Patrick, this is the solution I wrote:
** Parsing of untrusted input is entrusted to a dedicated Python script that is heavily confined using AppArmor.
** The original tbbversion function is still necessary to sanitize the output from this script.
** The script reads an input file, writes an output file, and gives an exit code indicating if the operation was successful. Console output to stderr ''is'' generated for debugging purposes, but is discarded by tbbversion.
** The exit codes are:
*** 0: Success.
*** 1: Invalid arguments.
*** 2: File I/O issues (file doesn't exist or cannot be read from/written to)
*** 3: Parse failure (invalid or malicious input)
** tbbversion runs a battery of checks against the returned value, ensuring it is small, contains only ASCII chars, non-empty, and looks like a valid version number. Once the full battery of tests passes, the value is considered trusted and is passed to tbbversion's caller.
** Callers source /usr/libexec/tb-updater/version-validator, set environment variables, and call tbbversion to do Tor Browser version parsing. This is identical to the previously existing API, with two exceptions:
*** tbbversion is now part of a script called version-validator. version-parser is now the confined Python script that does the real parsing. Thus scripts that rely on tbbversion need to be changed to source the correct script.
*** tbbversion supports Tor Browser ARM64 JSON from SourceForge. An environment variable tbb_version_parse_as_arm64 must be set to y to attempt to parse this JSON format.
** Code changes to tb-updater: https://github.com/ArrayBolt3/tb-updater/tree/arraybolt3/json-parse-hardening
** Code changes to developer-meta-files: https://github.com/ArrayBolt3/developer-meta-files/tree/arraybolt3/json-parse-hardening
** This is ready for review, a full test plan was developed, executed, and passed.
== archive.today link archiving ==
* mediawiki-shell already has code for downloading all wiki pages to the disk in mediawiki markup format, as well as parsing all local wiki text pages for links tool:
** mw-specific-backup-kicksecure
** mw-specific-backup-whonix
** git_mediawiki_backup_folder variable: todo
TMPFOLDER=/tmp/mediawiki-shell-temp \
wiki_backup_folder="$git_mediawiki_backup_folder" \
wiki_namespace_list_extra="274 500" \
"$tool"
* (FYI: this is used server-side to keep updating https://github.com/Kicksecure/kicksecure-wiki-backup / https://github.com/Whonix/whonix-wiki-backup)
* todo: implement and execute archival of all links using archive.today CLI, create a list of links and archived links (extendible format original-link, archive.today, archivebox, ...)
* todo: mass edit the wiki to add the archived links.
** Should we use a wiki template such as [[Template:Archive_link]]?
*** This might require a custom plugin, but I believe it should work. Archive.today works with links such as https://archive.today/https://google.com - clicking a link such as this will take you to a search page showing all of the archived copies archive.today has of that particular link so far. The user is then free to choose which version to look at
*** Custom mediawiki extension already existing: https://github.com/Kicksecure/mediawiki-link-to-archive
**** Moved to separate task.
**** It's already adding the web archive links.
**** Could be extended to add the archive.today links.
** Or only append the archive.today link behind the link?
*** Requires lots of manual work. The code I had that was rendering a fairly nice-looking archive "button" was something along the lines of [https://www.freedos.org/books/cprogramming/part5/ C Programming for DOS tutorial, part 5] [[Image:Archive-today-favicon.png|frameless|16px|link=https://archive.ph/https://archive.ph/https://www.freedos.org/books/cprogramming/part5/|text-top|Link to archive.today version]]. Using a plugin to automate that would be very valuable. Additionally, by doing this, we don't have to automatically archive every link someone adds (which CAPTCHAs make nearly impossible). People can simply archive the links as they add them, and people who find an unarchived link can archive it right then and there.
** To be kept in mind: if archive.today goes down one day, we might need to mass wiki edit to remove these links.
*** Use of a plugin like what we're using for the archive.org links should hopefully make that easy.
Plan #2:
* Current implementation plan for archiving:
** 1. Download all wiki pages from Kicksecure and Whonix wikis
** 2. Get all links from them
** 3. For each link, check if already in log file. If found, skip. If not continue.
** 4. search the link on archive.today
*** If found:
**** ok, skip
*** If not found:
**** Archive it
** When a CAPTCHA page is hit, stop and wait for the user to provide a new CAPTCHA cookie
** Needs a hardcoded list of excluded domain names. Some domains unfortunately can not be archived. Either failing or only unusable archived results. For example, archive.ph probably cannot archive web archive links.
update #2:
* no need to automatically re-archive links, can actually worsen the quality
* Tentatively finished archiver tool here: https://github.com/ArrayBolt3/mediawiki-shell/tree/arraybolt3/wiki-link-archiver Currently running this, it seems to be working well.
== kloak - add Qubes support ==
* review to understand the history:
** https://github.com/QubesOS/qubes-issues/issues/1850
* [https://github.com/QubesOS/qubes-issues/issues/8534 enable qvm-service gui-agent-virtual-input-device for Whonix-Workstation App Qubes by default]
** https://github.com/QubesOS/qubes-gui-agent-linux/pull/194
** https://github.com/QubesOS/qubes-app-linux-input-proxy/pull/30
* notify https://github.com/vmonaco/kloak/issues/74
Aaron:
* Final implementation needs orchestration, asked for advice from Qubes OS devs at https://github.com/QubesOS/qubes-issues/issues/1850#issuecomment-2374908358
* May also implement as part of GUI daemon, see https://github.com/QubesOS/qubes-issues/issues/8541#issuecomment-2377325699
* Ultimately we ended up using the GUI daemon approach.
== kloak - Qubes support - consider using Qubes API for orchestration ==
* https://github.com/QubesOS/qubes-issues/issues/1850#issuecomment-2374908358
* Waiting on response from Qubes OS devs
* Didn't end up doing this, kloak-like functionality has been merged into qubes-gui-daemon.
== document boot-repair ==
* Add to [[Broken Boot]]
* Decided against doing this. Boot-Repair has several features that upload system info and usage statistics to the Internet, some of which are potentially dangerous. The tool is useful when used properly, but it's too easy for someone to accidentally upload something they didn't want to upload.
== mediawiki-shell self-introduction ==
* Please look around in mediawiki-shell source code folder to get an idea about all its already existing functionality. This will be handy for follow-up tasks below.
* Done, got a good idea of the way it works and what features were needed for implementing the archiver.
== add py-archive-today to helper-scripts ==
* please add py-archive-today to helper-scripts as archive.today
* Done, https://github.com/ArrayBolt3/helper-scripts/tree/arraybolt3/archive-today
== automation of tb-updater hardcoded version number update - #2 ==
* please integrate with tb-updater
** has code to perform securely download tbb version number using upstream provided version file
** has code to parse tbb version number
** performs sanity testing
** there should only be 1 code path for download/parsing of tbb version in 1 repository
** Done, modified branch is at https://github.com/ArrayBolt3/developer-meta-files/tree/arraybolt3/tbb-version-detection-v2
== add archive.ph support to mediawiki-link-to-archive mediawiki extension ==
* Custom mediawiki extension already existing: https://github.com/Kicksecure/mediawiki-link-to-archive
* It's already adding the web archive links.
* Please add archive.ph links.
* Based on archive.ph supporting https://archive.today/https://google.com format.
* No testing required. (Because setting up a mediawiki test environment can be quite involved.)
* Branch with archive.today support here: https://github.com/ArrayBolt3/mediawiki-link-to-archive/tree/arraybolt3/archive-today
** Untested, however I did lint the code using php -l.
** See TODOs in code, this will not be usable as-is since an image needs added to the server and a CSS class may need to change.
** The intended result of the code is that an archive.today link icon will be added to every normal link, immediately after the archive.org icon. Onion links and archive.org links should ''not'' have an archive.today link icon added after them, whereas links to archive.today should have ''only'' an archive.today link icon added after them (with similar behavior to the existing link buttons for archive.org links and onion links).
== implement archive.today CLI frontend ==
* Use https://github.com/wabarc/archive.is/blob/main/cmd/archive.is/is.go as general guidelines
* Use as few dependencies as possible
** Currently using only the Python standard library and Requests.
** Implementation finished, temporary repo deleted, this is now at https://github.com/ArrayBolt3/helper-scripts/tree/arraybolt3/archive-today
== automation of tb-updater hardcoded version number update ==
* example of what is currently done manually:
** https://github.com/Kicksecure/tb-updater/commit/f1f48f57021502b7c0d17b7ce50929860e72244f
** https://github.com/Kicksecure/tb-updater/commit/9d790396a7439ceb6b8c494c790be6f80a304430
** notify forums https://forums.whonix.org/t/tor-browser-integration/11912/118
* post in forums can probably one day be avoided when there is packages.kicksecure.com which makes version numbers, changelogs more easily accessible including a "news blog" of recent changes
* On the surface, making this fully automated would likely require making commits to code in an automated fashion. This is a bit worrying to me since it requires a machine to have access to a non-password-protected, trusted GPG key that is used to automatically sign commits. This would potentially be a valuable target for an attacker, and could potentially introduce supply-chain attacks. Would it be sufficient to make this able to alert a sufficiently trusted person that it's time to update the version numbers? This could be combined with a tool that will update the version number to whatever is appropriate with a single command, allowing an administrator to simply run the command, verify the diff is correct, then commit and push.
* From chat with Patrick: "so in /usr/bin/dm-packaging-helper-script there could be a functional which shows the "git diff" before auto-committing, because then I can still stop it, should it look weird"
* Implemented. https://github.com/ArrayBolt3/developer-meta-files/tree/arraybolt3/tor-browser-version-update
== live-build - build broken - kicksecure repository apt-cacher-ng configuration ==
* This is the result of apt-cacher-ng HTTPS tunneling not being enabled on the CI server. Our sources.list files from repository-dist and anon-apt-sources-list are causing the problem.
* There is no practical, upstreamable way to only insert the sources.list files into the system after all apt commands have run. At best, it might be possible to insert our sources.list files immediately after sqaushfs-tools is installed but immediately before the squashfs is generated, then immediately delete them as soon as the squashfs was done being generated (as further apt commands are run after this point). This would be extremely hacky and would mandate that we keep our own live-build fork indefinitely, as such a change could not be practically upstreamed.
* Enabling apt-cacher-ng HTTPS tunneling is undesirable, as it could result in the wrong packages being used in the ISO build.
* One option might be to simply not install the sources.list files on the ISO at all, but rather have a script in the live session generate them, and have Calamares and debian-installer create them when appropriate. This goes against the design we want, but at this point it may be the only good solution.
* The solution we ended up using was to modify repository-dist to generate the derivative.list file when a particular systemd unit runs, then enable that system unit only when the --repo true option is set in derivative-maker. Options to repository-dist are passed via a file at /var/lib/repository-dist/derivative_apt_repository_opts, which is written at build time by the build system and then loaded at runtime by the systemd unit.
* Current fix branches:
** derivative-maker: https://github.com/ArrayBolt3/derivative-maker/tree/arraybolt3/apt-fix
** repository-dist: https://github.com/ArrayBolt3/repository-dist/tree/arraybolt3/deb-fix
== live-build - build failing due to fasttrack not using apt-cacher-ng syntax ==
* https://github.com/Whonix/derivative-maker/actions/runs/11794583611
* Fixed, also fixed a related bug with the kicksecure.com URL. Fix is present at https://github.com/arrayBolt3/derivative-maker
== test and review archive.today CLI frontend ==
* archive.today is interesting because it is an independent third-part
* candidate: wabarc/archive.is (supports CAPTCHA avoidance through cookie)
* https://github.com/wabarc/archive.is?tab=readme-ov-file#archivetoday-is-unavailable
** test for functionality first in a throwaway VM
*** Builds with Go 1.22 from bookworm-backports (sudo apt install -t bookworm-backports golang), to build you must go into the cmd/archive.is directory first, then go build
** test functionality and CAPTCHA avoidance
*** Searching appears to work without a CAPTCHA avoidance cookie, archiving requires the cookie.
*** Takes about a minute or two for a small page to be archived, then an additional five to ten minutes before that URL will show up when searched for using ./archive.is -p https://url in searches.
*** Tor is supported, but it's unclear how to make that support work, and research was inconclusive, filed a feature request to fix this at https://github.com/wabarc/archive.is/issues/58
** test archive.today onion (might help with CAPTCHA avoidance), will help with IP restrictions
*** http://archiveiya74codqgiixo33q62qlrqtkgmcitqx5u2oeqnmn5bpcbiyd.onion
*** TODO, need to figure out how to properly trigger the use of Tor first.
** review for malicious content
*** Reviewed main package code, no malicious content found. Code looked mostly straightforward, though it made use of some advanced Go techniques. The code does however have a number of dependencies, at least three of which are written by this tool's author and one of which is relatively obscure judging from the Github star count, so I want to review those too (and potentially their sub-dependencies as well).
** create a github fork from reviewed version (just pressing fork button, no other changes, unless required)
*** No fork created yet as I'm not yet ready to declare this safe, however the commit I have and am reviewing is f6bc92ea8a399df64d4772de73ecf695e48ac16b
* After initial investigation, we believe it will be safer and better to implement our own CLI frontend for this, using the Go code from wabarc's tool as inspiration.
== investigate doas ==
* determine if it's a suitable replacement for sudo in Kicksecure
** will using it resolve https://github.com/sudo-project/sudo/issues/415? It has to allow nopasswd exceptions to be distinguished from normal authentication in PAM
*** Yes, it will. I tested running a nopass command with doas and it did NOT reset the faillock counter. I checked the doas source code, and it looks like this is because doas nopass exceptions don't go through PAM at all (though I didn't thoroughly check the code so I'm not entirely sure of this).
* estimate work required to port to it
* Research and time estimate recorded at https://forums.whonix.org/t/replace-sudo-with-doas/17482/18.
== refactor dm-unicode-check ==
* https://github.com/Kicksecure/developer-meta-files/blob/master/usr/bin/dm-check-unicode#L47
* 1 line per entry for white list
* Done, branch is at https://github.com/ArrayBolt3/developer-meta-files/tree/arraybolt3/dm-check-unicode-enhance
== check live-build_installation function in derivative-maker ==
* todo
* Spot-checked, looked fine to me. Comment about improper live-build installation due to dependency packages mentioned to Patrick.
== build raw VM images - base images - consider porting from grml-debootstrap to live-build ==
* Building fully persistent images? Replacing grml-debootstrap?
--system normal
--binary-image hdd
* Useful? Low priority? arraybolt3: this would potentially be very useful, will investigate.
* Looks like this is potentially useful, but definitely needs a lot of help to make useful. To get a useful build, it was necessary to use the following configuration in auto/config:
#!/bin/sh
set -e
lb config noauto \
--distribution bookworm \
--system normal \
--binary-image hdd \
--hdd-size auto \
--chroot-filesystem none \
--binary-filesystem ext4 \
"${@}"
* The generated image contained no user account, no root password, and no properly configured fstab, thus it was necessary to mount the built image, chroot into it, configure fstab, add a user, and add the new user to the sudoers group.
* The generated image also used Syslinux as the default bootloader, which is obviously strange for a desktop system. Furthermore, the kernel command line was not configured properly, and it was necessary to manually add root=/dev/vda1 to the command line to get the system to boot. Probably should have set --bootloaders grub-pc,grub-efi. Unsure if --bootappend-live will work for setting the kernel command line, this may have to be fixed as a post-build operation (chrooting in and running sudo update-grub or similar).
* Was able to make a basic, mostly-working (aside from the bootloader issues) image with IceWM as the desktop.
* Patrick, paraphrased Aaron: While it might be doable to create fully persistent (VM) raw images using live-build, porting from grml-debootstrap to live-build is probably not worth it.
== refactor dm-packaging-helper-script ==
* Enhance readability and maintainability, document all functions and features
* Current iteration of refactor: https://github.com/ArrayBolt3/developer-meta-files/blob/arraybolt3/dm-packaging-helper-script-refactor/usr/bin/dm-packaging-helper-script
* Ready for final review. I did NOT change from using tee to using sponge because of the performance implications it would have (appending to a file with sponge will rewrite the entire file).
old (ok):
* kicksecure-meta-packages:
* Add xdg-desktop-portal(-gtk) (Thanks to Aaron Rainbolt!).
* No longer install `alsa-utils` by default https://forums.whonix.org/t/port-from-pulseaudio-to-pipewire-for-audio-support/16879/45.
* Add `accountservice` to `kicksecure-desktop-environment-essential-xfce`, which fixes error message:
* > localhost lightdm[911]: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .service files package `lightdm` `Suggests:` `accountservice`.
* Allow installation of `pipewire-media-session-pulseaudio` as an alternative to `wireplumber`.
...
new (bug):
* kicksecure-meta-packages:
* Fix ISO build failure (missing 's' in accountsservice) (Thanks to @ArrayBolt3!)
* kicksecure-meta-packages:
* Add xdg-desktop-portal(-gtk) (Thanks to @ArrayBolt3!)
* kicksecure-meta-packages:
* no longer install `alsa-utils` by default https://forums.whonix.org/t/port-from-pulseaudio-to-pipewire-for-audio-support/16879/45
* kicksecure-meta-packages:
* add `accountservice` to `kicksecure-desktop-environment-essential-xfce` fixes > localhost lightdm[911]: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .service files package `lightdm` `Suggests:` `accountservice`
* kicksecure-meta-packages:
* Bug fixed, forgot to set package_header_written='y' after writing the package header in pkg_git_packages_git_log_writer.
== audit grub profile pf2 files ==
* Files from upstream deleted, replaced with a Makefile that generates pf2 fonts from the Inter and Terminus fonts in the Debian archives at package build time. Also split out common GRUB theme code into dist-base-files.
* Repos modified:
** dist-base-files: https://github.com/ArrayBolt3/dist-base-files/tree/arraybolt3/grub-theme
** kicksecure-base-files: https://github.com/ArrayBolt3/kicksecure-base-files/tree/arraybolt3/grub-theme-fix
** anon-gw-base-files: https://github.com/ArrayBolt3/anon-gw-base-files/tree/arraybolt3/grub-theme-fix
** anon-ws-base-files: https://github.com/ArrayBolt3/anon-ws-base-files/tree/arraybolt3/grub-theme-fix
== live-build - build failing ==
* either live-build lb-dracut branch is not fully merged or forked live-build isn't installed by derivative-maker
* forked live-build wasn't being installed previously. Code for automatic installation written and tested, present at https://github.com/ArrayBolt3/derivative-maker/tree/arraybolt3/lb-autoinstall
== archive.today CLI ==
* since archive.org might go offline permanently, a quick replacement is required
* archive.today alternative domain names: archive.is, archive.ph (for search terms)
* todo: find a functional archive.today CLI tool
* todo: fork it, check if the code is static (does not load tons of other libraries) and is non-malicious
* arraybolt3: archive.today officially does not support automated archival of pages, see https://blog.archive.today/post/678411898279067648/hello-i-am-developing-an-application-that. They use CAPTCHAs to prevent automated tools from working, so it is unlikely such a tool exists, and even if it did, its use would potentially harm archive.today, and the tool would not function properly in the long run.
== continuous documentation effort - FYI only ==
* Patrick liked the new super grub disk additions to [[Broken Boot]]. If something else comes to mind, please continue improving the wiki.
== live build cdlabel change ==
* CDLABEL=Kicksecure_17
* --iso-volume 'Kicksecure 17' \\
* better set to just Kicksecure so the version number upgrade isn't needed and not forgotten in the future?
* set to Kicksecure already by Patrick
* arraybolt3: Fine with me, archiving.
== local editor settings - delete trailing spaces ==
* please kindly configure your local editor to deleted trailing spaces upon saving files
* Done.
== live-build - investigate options ==
* because it contains options and todo
* (originally from build-steps.d/1350_create-iso-config)
* not all comments might be needed. some of my comments might be superfluous / obvious.
old:
## folder derivative-maker/live-build can be re-created using:
## 2. help-steps/live-config
## Should not be done at live-build level if avoidable? Better done in package live-config-dist as /etc/default/grub.d drop-in
#--bootappend-live PARAMETER|"PARAMETERS"
# arraybolt3: Cannot be done via a package as the bootloader config for the ISO is set directly by live-build. Instead, source grub.d scripts from security-misc at build time and use variables from there to set the bootappend value.
# Patrick: Not only security-misc is setting grub configuration. Also other packages do or might in the future. Therefore all of /packages/ folder needs parsing.
# arraybolt3: We now use grub-mkconfig and config file parsing to automatically detect the proper GRUB kernel parameters.
## TODO: cleaner to not have these? better for reproducible builds?
#--apt-indices false
# arraybolt3: Added.
## Kicksecure enabled backports by default so live-build does not need to
## (kicksecure ships /etc/apt/sources.list.d/debian.list static file in package anon-apt-sources-list)
#--backports true|false
# arraybolt3: Left unset, seems to work.
## Probably not needed.
#--checksums md5|sha1|sha224|sha256|sha384|sha512|none
# arraybolt3: left unset
#--debian-installer cdrom|netinst|netboot|businesscard|live|none
# arraybolt3: This MUST be set to "--debian-installer=live" (different values other than "none" may also work?). Not doing so results in the on-CD apt repo that contains bootloader packages not being created, and alternate ways of making that repo ended up erroring out in my experiments.
## Kicksecure enables fasttrack repository by default. If build works, probably not needed.
#--keyring-packages PACKAGE|"PACKAGES"
# arraybolt3: left unset, but perhaps it should be set to include the fasttrack repository key. Currently I'm using "--debootstrap-options" to include it.
#--cache-stages "bootstrap rootfs"
# arraybolt3: left unset. This automatically "just works".
## For cross-build support.
# --architecture "$dist_build_target_arch"
# arraybolt3: Note that for cross builds to work, this must be paired with "--bootstrap-qemu-arch" if building for a foreign architecture like arm64. Needs testing.
# --distribution "$dist_build_apt_stable_release"
# arraybolt3: set.
## TODO: should we keep as is (Debian default) for better compatibility or set to
## $SHORT_VMNAME / $VMNAME (already defined in help-steps/variables) to avoid conflicts with Debian (dual-boot)?
# --hdd-label LABEL
# --image-name NAME
# --iso-application NAME
# --iso-publisher NAME
# --iso-volume NAME
# arraybolt3: all are now set
## Not applicable?
# --hdd-size SIZE
# arraybolt3: for ISO build, not applicable
## TODO: source not needed
# --source
# arraybolt3: left unset, defaults to false.
## yes. not bothering/mixing any other bootloaders such as isolinux (except shim, which live-build handles automatically)
# --bootloaders grub-efi
# arraybolt3: left unset, live-build figures this out automatically and generates an ISO that is both BIOS-bootable and UEFI-bootable with GRUB by default.
## already existing variable
# --linux-packages "$BUILD_KERNEL_PKGS"
# arraybolt3: set.
## already existing variable
## usability feature
## we want kernel headers installed by default (required for tirdad compilation (has a dependency); virtualbox guest utils (lacks dependency))
## probably
# --linux-packages "$BUILD_HEADER_PKGS"
# arraybolt3: set.
## We can probably set this because we cache using ${REPO_PROXY}? Double caching not useful?
## This option might have side effects.
# --cache-packages false
# arraybolt3: set `--cache false`.
## TODO: Does this work? Is our apt-cache-ng (already existing variable ${REPO_PROXY}) functional?
# --apt-ftp-proxy "${REPO_PROXY}"
# --apt-http-proxy "${REPO_PROXY}"
# arraybolt3: set, but unsure if it actually works yet
## important. using apt with --no-install-recommends
## but not setting and apt config file for the user
# --apt-recommends false \
# arraybolt3: already set.
## if using debootstrap
## important because we pull packages using packaging not using $debootstrap or live-build
# --debootstrap-options "--variant=minbase" \
# arraybolt3: set.
## if using mmdebstrap
## '--variant=required' is only supported by 'mmdebstrap'. It might not be supported by 'debootstrap'.
# --debootstrap-options "--variant=required" \
# arraybolt3: "required" and "minbase" appear to be treated identically by mmdebstrap, therefore not setting this.
## same as above
# --firmware-binary false
# --firmware-chroot false
# arraybolt3: already set.
## Seems correct.
# --binary-image iso-hybrid \
# arraybolt3: set.
lb config \
--distribution "$dist_build_apt_stable_release" \
--mirror-binary "$dist_build_apt_sources_mirror" \
--mirror-binary-security "$dist_build_apt_sources_security_mirror" \
--mirror-bootstrap "$dist_build_apt_sources_mirror" \
--mirror-chroot "$dist_build_apt_sources_mirror" \
--mirror-chroot-security "$dist_build_apt_sources_security_mirror" \
--mirror-debian-installer "$dist_build_apt_sources_mirror" \
--parent-mirror-binary "$dist_build_apt_sources_mirror" \
--parent-mirror-binary-security "$dist_build_apt_sources_security_mirror" \
--parent-mirror-bootstrap "$dist_build_apt_sources_mirror" \
--parent-mirror-chroot "$dist_build_apt_sources_mirror" \
--parent-mirror-chroot-security "$dist_build_apt_sources_security_mirror" \
--parent-mirror-debian-installer "$dist_build_apt_sources_mirror" \
--archive-areas "main contrib non-free non-free-firmware" \
# arraybolt3: set.
## use $dist_build_apt_stable_release instead of hardcoded "bookworm"
--distribution "bookworm"
# arraybolt3: no longer hardcoded.
## probably needed? same as Kicksecue default APT sources archive areas
## should we get this by parsing? in buildconfig.d/25_apt_sources.conf
--archive-areas "main contrib non-free non-free-firmware" \
# arraybolt3: set. Getting from 25_apt_sources.conf is not ideal because it does not have a simple variable that can be used for this purpose.
## sources not needed
--apt-source-archives false \
# arraybolt3: set.
--source false \
# arraybolt3: defaults to false, does not need set.
## zsync not used
--zsync false \
# arraybolt3: set.
## useful? irrelevant?
# --chroot-filesystem ext4 \
# --binary-filesystem ext4 \
# arraybolt3: both seem irrelevant.
## useful to see what is going on. why not.
# --verbose \
# --debug
# arraybolt3: set.
## sanity testing and nice to compare logs
lb config --dump
lb config --validate
# arraybolt3: integrated.
## better verbose than not knowing what is going on
lb build --verbose --debug
# arraybolt3: integrated.
* Reviewed and integrated.
== ISO - port to live-build ==
* check derivative-maker source code git history: previously there was a port to live-build. Useful to resurrect it? [DONE]
* port to live-build
* make use of Debian's dracut branch for live-build [DONE]
* add live-build git submodule to derivative-maker (as long all our changes aren't upstreamed)
* Ensure --remote-derivative-packages still works [DONE]
* Test building Kicksecure on top of Kicksecure [DONE]
* live-config-dist fork needed for installer to work with live-build ISO: https://github.com/ArrayBolt3/live-config-dist/tree/arraybolt3/live-build
* dist-base-files fork needed for proper user account generation: https://github.com/ArrayBolt3/dist-base-files/tree/arraybolt3/live-build
* anon-apt-sources-list fork needed to avoid a naming conflict with live-build: https://github.com/ArrayBolt3/anon-apt-sources-list/tree/arraybolt3/live-build
* live-build fork: https://salsa.debian.org/ArrayBolt3/live-build/-/tree/arraybolt3/lb-dracut?ref_type=heads
** All changes submitted upstream, TODO work with upstream to get these polished and merged
* derivative-maker fork with live-build support: https://github.com/ArrayBolt3/derivative-maker/tree/arraybolt3/live-build
* PR: https://github.com/Kicksecure/derivative-maker/pull/2
== Whonix grub-theme ==
* similar to above
* add to https://github.com/Whonix/whonix-base-files
** Branch at https://github.com/ArrayBolt3/whonix-base-files/tree/arraybolt3/grub-theme, moved 30_whonix.cfg to 25_whonix.cfg and used rm_conffile to remove the old version
* possible make a slightly different theme for [https://www.whonix.org/wiki/Whonix-Host Whonix-Host], [https://www.whonix.org/wiki/Whonix-Gateway Whonix-Gateway] and [https://www.whonix.org/wiki/Whonix-Workstation Whonix-Workstation]?
** https://github.com/Whonix/anon-gw-base-files
*** Branch containing theme at: https://github.com/ArrayBolt3/anon-gw-base-files/tree/arraybolt3/grub-theme
** https://github.com/Whonix/anon-ws-base-files
*** Branch containing theme at: https://github.com/ArrayBolt3/anon-ws-base-files/tree/arraybolt3/grub-theme
** Whonix-Host not yet dealt with, can add a specific GRUB theme for it when desired.
== Kicksecure grub-theme ==
* maybe https://github.com/AdisonCavani/distro-grub-themes can be helpful?
* add to https://github.com/Kicksecure/kicksecure-base-files
* With the way Debian is designed, the proper way to do this (as far as I can tell) is to pull in the desktop-base package, then use the alternatives system to override the Debian artwork with vendor-specific artwork. However there is a LOT more artwork than just GRUB themes that has to be overridden here. Currently working on this, I think the best package to do this in would be desktop-config-dist although I'm not certain.
* Possible issues with current implementation:
** Potential aspect ratio weirdness, we may or may not care. Debian uses 4x3 aspect ratio for BIOS and 16x9 aspect ratio for UEFI, I've followed that convention here.
* investigate if dh_link can used to create symlinks
** arraybolt3: dh_link is part of debhelper, which is a tool intended for use only at package build time. It is not intended to be used at maintainer script run time to my awareness, and using it in this context would require pulling in debhelper as a dependency, which would be weird because debhelper is a developer tool, not an end-user tool. Thus I don't think we should do this. ln works fine here and makes sure that the proper GRUB screen sizes are used.
* Implemented at: https://github.com/ArrayBolt3/kicksecure-base-files/tree/arraybolt3/grub-theme
== dummy-dependency improvements ==
* use Provides:
* please merged my changes / work on top of Patrick changes (Kicksecure/helper-scripts)
* Latest update: https://github.com/ArrayBolt3/helper-scripts/tree/arraybolt3/dummy-dep-generator
== upgrade-nonroot comment ==
* please see https://forums.whonix.org/t/qubes-sudo-su-root-hardening-development-discussion/8561/43 and add comments, if any
* Added comment at https://forums.whonix.org/t/qubes-sudo-su-root-hardening-development-discussion/8561/45
== zswap commment ==
* please comment on https://forums.kicksecure.com/t/enable-and-use-zram-instead-for-swap/654/1
* Commented at https://forums.kicksecure.com/t/enable-and-use-zram-instead-for-swap/654/2, probably prefer zswap solution over zram
* update 1: https://forums.kicksecure.com/t/enable-and-use-zram-instead-for-swap/654/7
* Replied at https://forums.kicksecure.com/t/enable-and-use-zram-instead-for-swap/654/8, I meant to reply to this before and then forgot
== minimize grub themes ==
* please remove all files that are only required for pretty multiboot (without breaking actual multiboot)
* Done, same repositories and branches are still in use.
== document grub.cfg extraction methods or chainloading ==
* Worthy of note, the Linux boot entries are only populated if the disk is unencrypted. Encrypted systems require the use of one of the grub.cfg extraction entries, or (in the case of BIOS systems) chainloading. Additionally, it would be recommended to always use the grub.cfg extraction methods or chainloading, as the use of a "normal" Linux boot entry works but does not enable any kernel hardening features.
* please add to wiki ([[grub]]?)
* Documented under [[Broken Boot]], along with detailed instructions on installing and using Super Grub2 Disk.
== dummy-dependency package generator ==
* helper-script (or usability-misc?) to use equivs (or similar small dependency) to generate a dummy-dependency
* dummy-dependency script written, branch is at https://github.com/ArrayBolt3/helper-scripts/tree/arraybolt3/dummy-dep-generator
== review and refactor meta packages ==
* https://github.com/Kicksecure/kicksecure-meta-packages
* https://github.com/Whonix/whonix-meta-packages
** Review, suggestions for refactoring: https://gist.github.com/ArrayBolt3/1312aa401d0b7ade970210b3f526f9e8
* please review, discuss
** Forum post at https://forums.kicksecure.com/t/metapackages-tweak-suggestions/663 to get feedback on suggested changes
* purpose of this task is to address and (maybe required) refactoring, bug fixes in preparation for the future, maintainability, next task below
Update 1:
* please proceed with the "small" tasks that can be done safely during Debian bookworm based releases
* create a ticket for Debian trixie port
* Update for Kicksecure metapackages: https://github.com/ArrayBolt3/kicksecure-meta-packages/tree/arraybolt3/relocate-packages
* Update for Whonix metapackages: https://github.com/ArrayBolt3/anon-meta-packages/tree/arraybolt3/relocate-packages
== kloak readme fix ==
* https://github.com/Whonix/kloak/issues/4
* Fixed in https://github.com/ArrayBolt3/kloak/commit/9c57eba2e77082f1967ec54a0a42226843df7f17
== live-build - source code integration into derivative maker ==
* assume at in derivative-maker/live-build
* Done by Patrick.
== live-build - use live-build to create grub.cfg GRUB configuration ==
* Possible?
* Not possible due to live-build's design, we apply a lot of customisations here that probably should not be upstreamed.
== live-build - remove unicode ==
* please remove unicode if possible from live-build/share/bootloaders/splash.svg
* Fixed, pushed to my fork of live-build. Looks like there were two non-breaking spaces causing issues. This probably cannot be upstreamed as one assumes these were made non-breaking for a reason, and while we may not care about that reason, they probably do.
== review Super Grub2 Disk ==
* see https://github.com/supergrub/supergrub/tree/master/menus/sgd
* any cool/needed features there which would be useful to add to the ISO or non-ISO boot process?
* Don't see much extra that is needed there if it works reliably. The tool appears very capable, I was able to use it to boot an installed Kicksecure system in several different ways. Also was able to loopback boot ISOs. If a user runs into a problem trying to use it for boot recovery, then we should add a task to fix the issue to this list.
== confidential computing ==
* Please read tickets from private issue tracker and update [[Dev/confidential computing]] with new contents based on that.
* Read, added notes on tamper protection and generation of one's own Secure Boot keys.
== append-once bug ==
livecheck:
append-once "${save_file}" "${click}"
append-once "${save_file}" "${click}"
Does not work. Only the first "click" gets appended. "txtclick" is missing. This is a bug in append-once.
(Patrick applied a workaround in livecheck for now.)
Please fix append-once, if possible.
* arraybolt3: Fixed by making a variant of the str_replace script called str_match and using it in lieu of grep. Also caught a bug with livecheck in general due to running lsblk too early.
** helper-scripts change branch: https://github.com/ArrayBolt3/helper-scripts/tree/arraybolt3/append-once-fix
** desktop-config-dist change branch: https://github.com/ArrayBolt3/desktop-config-dist/tree/arraybolt3/livecheck-fix2
== live-build - fork of live-build ==
* please create fully merged live-build repository on github so Patrick can fork it and add the git submodule to derivative-maker
* Fork publicized at https://salsa.debian.org/ArrayBolt3/live-build/-/tree/arraybolt3/lb-dracut?ref_type=heads
* Synced with upstream as of 2024-10-25, includes the merge of Dracut support to master.
== live-build - use derivative-maker variable APT_OPTIONS ==
* for reference, see derivative-maker help-steps/variables APTGETOPT, APTGETOPT_ALT, APTGETOPT_WITHOUT_APT_CACHE
* set live-build APT_OPTIONS to APTGETOPT
* these include --error-on=any and more
* Added.
== live-build - avoid live-build specific boot splash ==
* https://github.com/ArrayBolt3/derivative-maker/blob/arraybolt3/live-build/live-build-data/splash.svg
* Avoidable? Can be done in /packages/ instead please?
** Difficult to avoid, the splash screen is dynamically modified by live-build at build time, and is sourced from live-build's configuration directory at build time (live-build does not use packages installed under the chroot to find this). The entirety of the bootloader configuration is done without use of packages installed in the built system as I understand it.
* there are later tasks for GRUB boot menu styling
** This has to be dealt with now because otherwise we risk causing confusion to end-users. The default GRUB splash on live-build ISOs uses a strange construction hat logo, and states that the ISO is specifically Debian. Not changing this screen could even be legally problematic as the name "Debian" is a trademark. (https://www.debian.org/trademark) This GRUB screen is also specific to live-build and should not be used for installed systems. Debian uses separate GRUB screens for installed systems and live-build ISOs.
* live-config-dist uses to add "Live ISO" to grub boot menu in https://github.com/Kicksecure/live-config-dist/blob/master/etc/default/grub.d/40_live-config-dist.cfg - possible to do the same with live-build?
** This file should probably be deleted once live-build becomes the default ISO build mechanism.
* Figure out what unicode is in the splash screen SVG and remove it if at all possible
** Fixed, it was a non-breaking space.
== report TCP ISN specification issue ==
* TCP ISN is an issue in the spec
* Could you please report this upstream in to the spec, if possible?
* Reported.
== live-check - run once only ==
* to avoid log spam (passwordless root)
* create a done file in folder /run/user/$USER so the livecheck script does not run sudo over and over again
* https://github.com/ArrayBolt3/desktop-config-dist/tree/arraybolt3/livecheck-fix Tested and ready for review/merge.
== review kloak RPM specfile ==
* https://github.com/Whonix/kloak/pull/2
* please review for non-maliciousness only
* Reviewed, all contents appear normal, useful, and non-malicious. However, the systemd unit for kloak is not enabled by default due to the lack of a systemd preset file. This may be something we want to resolve later.
== desktop-config-dist - livecheck - rd.live.image ==
* FYI: this is now fixed in git. no more patch for live-build required. livecheck should now work out of the box (no matter if old or new live-build kernel parameters)
* FYI only. Ticket can be archived.
* arraybolt3: I haven't archived this yet since it doesn't seem to actually be working in my ISO builds and I'm not sure why.
* Patrick: Fixed yet again.
* arraybolt3: Looks good now.
== automate VirtualBox version update in the wiki ==
* example what is being done manually: https://www.kicksecure.com/w/index.php?title=Template%3AVirtualBox_Host_Software_Installation&diff=87404&oldid=86914
* suggestions on how to automate this? using mediawiki-shell
* automation of the script that does the change?
* automation to auto run that script?
* add to developer-meta-files
* Prototype code: https://github.com/ArrayBolt3/auto-version-update
* Final code, ready for review: https://github.com/ArrayBolt3/developer-meta-files/commit/d053175dd27beb6eee8ad853a35efb57928e4f04
== calamares - change to BTRFS by default - including subvolumes ==
* change to BTRFS by default
* make use of subvolumes
* https://forums.kicksecure.com/t/use-btrfs-as-the-default-journaling-file-system/626
* Added btrfs-progs to kicksecure-recommended-cli: https://github.com/ArrayBolt3/kicksecure-meta-packages/tree/arraybolt3/btrfs-support (necessary to avoid installation failures)
* Added BTRFS support to live-config-dist: https://github.com/ArrayBolt3/live-config-dist/tree/arraybolt3/btrfs-support
* Note that Calamares installs BTRFS with subvolumes on the root filesystem by default, so no special work was needed to make that happen.
== live-build - path may be being set in a non-ideal fashion ==
* $source_code_folder_dist/live-build for the git sub module (our fork) (pristine source code)
* $dist_binary_build_folder/live-build should be used for the "config" folder (which will contain binaries after running live-build) (can be safely deleted and re-created using derivative-maker)
** arraybolt3: currently using $dist_binary_build_folder/kicksecure-live-build for this, change to use live-build name instead
** Done.
== live-build - boot-time scripts handling ==
* boot-time scripts aren't marked as executable
* the boot-time scripts are an implementation detail of the live-build config (used to set the default shell to ZSH and change the username from "Debian live user" to "Kicksecure live user")
* should be done by to /packages/
** arraybolt3: This cannot be done by /packages/ because these scripts are installed by live-build and are not vendored as a package. This is the recommended way of doing things in live-build, see https://live-team.pages.debian.net/live-manual/html/live-manual/customizing-contents.en.html#customizing-contents section "9.2.3 Boot-time hooks"
** Patrick:
*** Where is the source code for these scripts?
**** arraybolt3: Integrated in derivative-maker/build-steps.d/2800_create-lb-iso.
*** Can we avoid using some of these scripts? Is this a missing live-build feature? If it is what I vaguely remember before, these could be disabled with a symlink to /dev/null inside the configuration folder.
**** arraybolt3: The scripts are custom-written for the ISO, and have two purposes - one of them renames "Debian live user" to "Kicksecure live user", the other one changes the default shell in the ISO live environment from bash to zsh.
*** Switching default shell from bash to zsh is already implemented in dist-base-files debian/dist-base-files.postinst. It also supports configuration, simplifies customized builds / forks. Doing this in dist-base-files as well as on the live-build level, adds extra complexity, which should be avoided.
**** arraybolt3: Doing this in a package requires shipping files under /lib/live/config. This is because the live session user on the ISO is actually created ''at ISO boot time'', not at build time. As a result the user's default shell and most of the user configuration is controlled by live-build boot-time hooks, which are located in /lib/live/config. Technically this is doable, but it diverges from the documented method described in live-build's manual.
* All extra boot-time scripts have been made obsolete and are thus removed.
== live-build - avoid scripting at calamares level - avoid /etc/calamares/modules/shellprocess_useradd.conf ==
* Can this be done at /packages/ level instead please?
** Very difficult. live-build ISOs generate the user account on the ISO at boot time, meaning that after an initial Calamares installation, the installed system has no usable user account. Creating one requires either using the Calamares users module (which as previously discussed is undesirable) or requires a hook similar to what is implemented with shellprocess_useradd.conf.
* Already implemented in dist-base-files debian/dist-base-files.postinst
** This should not be implemented here. This method of implementation is fundamentally incompatible with live-build, and the only reason it hasn't caused issues is because the logic disables itself when not running under Qubes or derivative-maker, and when live-build is running it obscures the use of derivative-maker from the package.
* Better to keep it there due to planned changes. (User "user" will no longer be a member of group "sudo" and a new user "admin" will be introduced.) Otherwise having two places to maintain this would complicate things.
** Can it be moved to live-config-dist and maintained there going forward?
* shellprocess_useradd.conf removed, user creation managed by dist-base-files as before.
== livecheck - FYI - rd.live.image kernel parameter detection broken==
* fixed in git
* FYI only
* please archive this ticket
== live-build - upstream pull requests ==
* Please check, continue working with upstream.
* Updated fork to reflect new changes to master, commented on the localrepo merge request.
* All three live-build patches are listed in "WAITING ON", indicating that work on them is ongoing. I will make sure to monitor activity there regularly and respond quickly.
* Patrick: This was about:
Merge blocked: 1 check failed
Merge request must be rebased, because a fast-forward merge is not possible.
== pam_faillock ticket ==
* What runs /etc/pam.d/sudo versus /etc/pam.d/sudo-i? No other file in /etc/pam.d references such a file.
** sudo's source code allows sudo to identify itself to PAM as either sudo or sudo-i depending on how sudo is being used. See https://github.com/sudo-project/sudo/blob/17aa7688c955e58adffdfb0300d485a2b859b128/plugins/sudoers/auth/pam.c#L220. Theoretically it might be possible to patch this location in sudo to make it identify itself to PAM in a special manner when running a NOPASSWD command.
** Bug report filed against sudo: https://github.com/sudo-project/sudo/issues/415
* Useful to add? https://github.com/linux-pam/linux-pam/issues/842
`/etc/pam.d/sudo`
```
#%PAM-1.0
# Set up user limits from /etc/security/limits.conf.
session required pam_limits.so
@include common-auth
@include common-account
@include common-session-noninteractive
```
`/etc/pam.d/sudo-i`
```
#%PAM-1.0
# Set up user limits from /etc/security/limits.conf.
session required pam_limits.so
@include common-auth
@include common-account
@include common-session
```
----
`/etc/sudoers.d/upgrade-passwordless`
```
%sudo ALL=NOPASSWD: /usr/bin/apt-get-update-plus dist-upgrade
```
* May be useful, but I don't believe it is necessarily useful right now. Would like to wait for now.
** Patrick: Agreed because this bug seems to be a sudo bug instead and was reported against sudo.
* Ticket can be archived.
== fix broken recovery mode ==
* Recent Kicksecure ISOs seem to simply hang during boot when booted in recovery mode. Investigate.
* Turns out the default kernel in the latest ISO has a broken recovery mode. However, the next kernel update thereafter works without issues. This will therefore resolve itself during regular updates, and the next ISO build should have it fixed.
== live-build - keep generated live-build folder out of source code folder ==
* treat "lb config" as pristine/source code
* place live-build folder in ~/derivative_binary folder (use already existing variable binary_build_folder_dist)
* reason: live-build mixes config and binaries inside the same folder
This is how it was done in the past:
mkdir --parents "$binary_build_folder_live_build"
cd "$binary_build_folder_live_build"
* live-build config is autogenerated at build time now.
== review root related documentation ==
* read
* improve
* https://www.kicksecure.com/wiki/Dev/Strong_Linux_User_Account_Isolation
** Read, added improvements including rewriting the console login attacks section.
* https://www.kicksecure.com/wiki/Root
** Read, added improvements including documenting how to run GUI applications as root under Wayland
* https://www.kicksecure.com/wiki/Default_Passwords
** Read, didn't see anything that needed added.
* https://www.kicksecure.com/wiki/Protection_Against_Physical_Attacks
** Read, fixed a link and clarified some things related to IOMMU.
* https://www.kicksecure.com/wiki/Dev/boot_modes
** Read, didn't see anything that needed added.
== faillock ==
=== security-misc - review pam-configs ===
* please have a look here in security-misc usr/share/pam-configs/ for introduction
* Looked at it, seems reasonable and useful
* Found documentation for pam-configs at https://wiki.ubuntu.com/PAMConfigFrameworkSpec
=== security-misc - faillock - stop reset after reboot ===
* should not be reset after reboot
* the faillock status file is configureable already, see man pam_faillock
* Requires pam config modifications to make work right, working proof-of-concept config determined and shared in chat.
* Fixed in commit https://github.com/ArrayBolt3/security-misc/commit/690e8dd826d1cb39c0c12c03792781862cc2dd23
=== security-misc - faillock - stop reset after 24 hours ===
* should not be reset after 24 hours
* no need to automatically reset at all
* user should always have a chance to learn about failed login attempts
* this can (likely?) be configured in our already existing configuration file in security-misc
* Lockout reset is preventable, tally reset cannot be configured out and the largest possible delay between resets that can be set is arbitrarily limited to 7 days.
* Fixed as much as possible in commit https://github.com/ArrayBolt3/security-misc/commit/690e8dd826d1cb39c0c12c03792781862cc2dd23
== security review ==
* as discussed
* done, notes shared in chat
== live-build - stop installation extraneous packages ==
* dhcp / networking related packages
* whiptail
* should not be pulled by live-build
* if deemed useful packages, needs to be discussed in forums and and done inside the derivative-maker /packages/ folder through Depends:
* Looks like this is solved, cannot find isc-related packages, ifupdown, or whiptail in my latest build.
== live-build - dracut related fixes ==
* please report and/or fix upstream anything dracut related that needs fixing due to new results with live-build
* Reported the one main issue I ran into at https://salsa.debian.org/live-team/live-build/-/merge_requests/353#note_537378, verified that other issues I had encountered were no longer a problem.
== kloak - add support for /dev/input/mice ==
* 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.
** probably user error. archiving.
== ISO - check git history ==
* check derivative-maker source code git history as it might have useful options
* Found and extracted lb config command. Commit used was from 2023-07-20, and is the latest live-build commit on that day.
== desktop-config-dist package version issue ==
* kicksecure /dists/bookworm-developers/main/binary-amd64/Packages
Package: desktop-config-dist
Version: 3:10.1-1
desktop-config-dist(master)]% git describe
10.1-1
* todo: investigate
** How did an outdated desktop-config-dist version (older than in git) end up in the test ISO? Did it install packages from local repository? Then this issue should be impossible to happen. Or did it test wise use the remote, stable repository? Then this is not surprising. The stable repository often has older versions. These are for the most part only updated once a new stable release has been released.
* note: updated due to below now
* The version of the desktop-config-dist package installed on the ISO had contents older than in Git, but the version number was *newer*. This leads me to believe that most likely the machine used to build the ISO had testing code left in derivative-maker/packages/kicksecure/desktop-config-dist or similar.
== research chvt security impact ==
* in context of root
* Researched and added to console login attacks section of https://www.kicksecure.com/wiki/Dev/Strong_Linux_User_Account_Isolation. Does not appear to be a concern.
== tirdad - fix ==
* please send a pull request for the recent tirdad fix to Kicksecure/tirdad
* Merge commit at https://github.com/ArrayBolt3/tirdad-kicksecure/commit/2301b1c1413d8013b5c3b30976732bbf23d2f9ac, cannot open pull request due to having a fork of upstream already in my account.
== Security Through Amnesia: A Software-Based Solution to the Cold Boot Attack on Disk Encryption ==
* https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=e5f940decaa589f3b2030429f48739281839e4d8
* please read
* add to [[Dev/confidential computing]]
* Added notes, including one about a potential attack vector via NMIs.
== wiki improvements related to Open Source hardware and firmware ==
* https://www.kicksecure.com/wiki/Open-source_Hardware
* https://www.kicksecure.com/wiki/Out-of-band_Management_Technology
* check for correctness
* improve these pages
* Added notes about OpenPOWER to the open-source hardware page.
* Added notes about Computrace to the out-of-band management page.
== e-mail processing ==
* read e-mail on confidential computing, digest, add to wiki (cannot be copied/pasted)
* Added notes to confidential computing page.
== keepassxc org.freedesktop.secrets Linux distribution compatibly feature request ==
* Shortcoming have been identified in https://forums.kicksecure.com/t/error-storing-passphrase-in-keyring-the-name-org-freedesktop-secrets-was-not-provided-by-any-service-files/582/2
* Post a feature request for kepassxc what kind of changes they would have to make so keepssxc can be easily used as a org.freedesktop.secrets provider as a Linux distribution.
** Feature request at https://github.com/keepassxreboot/keepassxc/issues/11342
* kepassxc would probably need an /etc/kepassxc.d drop-in configuration folder where a distribution could add a configuration snippet to enable this functionality.
* Post the link to the feature request in the forum thread.
** https://forums.kicksecure.com/t/error-storing-passphrase-in-keyring-the-name-org-freedesktop-secrets-was-not-provided-by-any-service-files/582/4
== research enclaive ==
* https://github.com/enclaive
== research constellation ==
* https://github.com/edgelesssys/constellation
** https://www.edgeless.systems/press-release-edgeless-systems-releases-first-runtime-encrypted-kubernetes-as-open-source
* https://www.edgeless.systems/docs/
* https://docs.edgeless.systems/continuum/
* https://docs.edgeless.systems/continuum/security-goals
* https://docs.edgeless.systems/continuum/attestation/overview
* https://www.edgeless.systems/products/contrast
* Added Constellation, Contrast, and Continuum to Confidential Computing page with notes (Constellation looks particularly handy if one trusts a silicon vendor)
== research Intel TDX ==
* https://en.wikipedia.org/wiki/Trust_Domain_Extensions
* https://www.intel.com/content/www/us/en/developer/tools/trust-domain-extensions/overview.html
* https://github.com/intel/tdx-module
* https://azure.microsoft.com/en-us/blog/azure-confidential-computing-on-4th-gen-intel-xeon-scalable-processors-with-intel-tdx/
* Integrated research into confidential computing page.
== ISO - wrong bootloader entry ==
* https://forums.kicksecure.com/t/boot-issue-after-installking-kicksecure/602/16
* Unsure why this happened. Debian's Wiki has a recorded instance of this happening (at the bottom of https://wiki.debian.org/GrubEFIReinstall) and the suggested workaround is to install rEFInd instead of GRUB.
== ISO - fallback boot loader broken ==
* 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_path). 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 ==
* On the first page of calamares installer the Kicksecure logo looks a bit out of place because it is way to large. Please reduce the size a bit.
* Done in https://github.com/ArrayBolt3/live-config-dist/commit/15eb4be99fd5d933c3067c982a9a6ad3f4d06d23
== ISO - calamares - encrypt button bug ==
* See video provided.
* Followed up with Calamares developers. There don't appear to be blockers, the devs are just short on time and haven't gotten around to merging the fix yet.
* https://github.com/calamares/calamares/pull/2376
* https://github.com/calamares/calamares/issues/2375
* https://github.com/calamares/calamares/issues/2379
== ISO - live-config - dist shellprocess_fixconkeys_part ==
* 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/2383
== research Secure Cloud Hardware ==
* [[Dev/confidential_computing#Secure_Cloud_Hardware_TODO_Research_List|Secure Cloud Hardware TODO Research List]]
* Done, notes added to confidential computing Wiki page.
== research AMD Infinity Guard ==
* https://www.amd.com/en/products/processors/server/epyc/infinity-guard.html
* https://www.kicksecure.com/wiki/Dev/confidential_computing#AMD_Infinity_Guard
* Added a note to the confidential computing page, this is basically just branding for a number of other technologies, all of which are either not directly relevant or have been previously covered.
== tirdad ==
=== tirdad - read history and old discussions ===
* https://dl.acm.org/citation.cfm?id=1180410
* https://forums.whonix.org/t/tcp-isn-cpu-information-leak-protection-tirdad/8552
* https://phabricator.whonix.org/T543 -> broken link -> nowadays -> https://forums.whonix.org/t/cpu-induced-latency-covert-channel-countermeasures/18875
* https://trac.torproject.org/projects/tor/ticket/16659 -> https://gitlab.torproject.org/legacy/trac/-/issues/16659
* Read through all linked information.
=== tirdad - functionality review ===
* please investigate tirdad more closely
* https://bitguard.wordpress.com/2019/09/03/an-analysis-of-tcp-secure-sn-generation-in-linux-and-its-privacy-issues/
* check references, theory, implementation
* Reviewed, theory makes good sense, implementation could be improved but that's for future tasks
=== tirdad - backports compatibility ===
* currently failing to compile using backports kernel
* https://forums.whonix.org/t/using-kernels-from-backports/20503/5
* https://github.com/0xsirus/tirdad/issues/24
* please check if https://github.com/0xsirus/tirdad/commit/4720311ff21c3f71cc5e3670caf5dfde2b31c5f8 looks good and test
* Verified that this commit does indeed fix the issue.
=== tirdad - fix code issues ===
* 1 pull request per issue as found in your security review
* Some of the pull requests ended up fixing multiple issues simply by virtue of the fact that fixing some of the issues resulted in problematic code being removed entirely and thus no longer a concern.
* Pull requests:
** https://github.com/0xsirus/tirdad/pull/25
** https://github.com/0xsirus/tirdad/pull/26
** https://github.com/0xsirus/tirdad/pull/27
=== tirdad - upstream to Linux ===
* please discuss upstream
* see if it is possible to send a pull request upstream
=== tirdad - compile time hardening flags review ===
* 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 ===
* https://lwn.net/Articles/455270/
* 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 ===
* 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 ==
* increased priority because the user is still available
* https://forums.kicksecure.com/t/boot-issue-after-installking-kicksecure/602
* The user might be no longer available. But for the future, can we have a checklist on how to debug the boot process?
* Perhaps even a pre-installed script that can be run from live mode or from inside the broken system (if it is known that it would be no longer bootable after reboot)?
* https://packages.debian.org/bookworm/boot-info-script is already installed by default. Helpful?
* Please document here: [[Broken Boot]]
== research AMD TSME ==
* https://www.kicksecure.com/wiki/Dev/confidential_computing#AMD_TSME
* sounds better than SME
* Researched and notes added to confidential computing doc.
== investigate locale issue ==
* https://forums.kicksecure.com/t/locale-layout-installation-error/611
* Issue identified and fixed: https://github.com/ArrayBolt3/live-config-dist/commit/fe3eb5da1a8a2c464026941c572e61de90d3e6e6
== tirdad ==
=== security review tirdad.c ===
* please review for code safety issues (memory safety)
* security review only for now
* functionality review at a later point
* https://github.com/Kicksecure/tirdad/blob/master/module/tirdad.c
* please report issues, if any, upstream: https://github.com/0xsirus/tirdad
* https://chatgpt.com/share/67029e9f-8e30-8000-9a22-114ff13c2b93
* Review at https://github.com/0xsirus/tirdad/issues/23
== hardware security features for RamCrypt ==
* 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 ==
* GTK should not be using hardcoded device names to detect "fake" touchscreens
* https://forums.whonix.org/t/weird-magnifier-feature/20502/12
* Reported at https://gitlab.gnome.org/GNOME/gtk/-/issues/7060
== investigate kloak bugs ==
* https://forums.whonix.org/t/weird-magnifier-feature/20502
** "marking text in mousepad shows magnifier" (confirmed by Patrick)
** "marking text in thunar shows magnifier" (confirmed by Patrick)
** "mousepad app I can scroll a long text as if I were swiping up and down with a touchscreen device" (not reproducible by Patrick)
** "no highlighting of mouse context menu and no highlight on system wide menu" (not understood)
** Turns out to be because of how GTK handles "fake" touchscreens, see https://forums.whonix.org/t/weird-magnifier-feature/20502/12
** Fixed in https://github.com/Whonix/kloak/commit/d4e7b4c0428527ea002e1ea61839effc0cb5e88e
== research Intel / AMD RAM Encryption ==
* https://www.amd.com/content/dam/amd/en/documents/epyc-business-docs/white-papers/memory-encryption-white-paper.pdf
* https://www.intel.com/content/www/us/en/developer/articles/news/runtime-encryption-of-memory-with-intel-tme-mk.html
* https://www.kernel.org/doc/html/next/x86/amd-memory-encryption.html
* https://www.trentonsystems.com/en-us/resource-hub/blog/what-is-intel-tme
* https://forums.whonix.org/t/enable-secure-memory-encryption-sme-kernel-parameter-mem-encrypt-by-default/10393
* https://en.wikichip.org/wiki/x86/sme
* https://en.wikichip.org/wiki/x86/tme
* Researched and added to Whonix Dev/cloud page. tl;dr: AMD SEV and SME does not seem suitable. Intel TME-MK appears promising.
== pKVM research ==
* 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 ==
* https://github.com/dracut-ng/dracut-ng/issues/684
* https://github.com/dracut-ng/dracut-ng/pull/609
* Tested commit, followed up at https://github.com/dracut-ng/dracut-ng/issues/684#issuecomment-2394398786, this is done
== calamares luks encryption settings ticket ==
* please reply https://github.com/calamares/calamares/issues/2374
* replied: https://github.com/calamares/calamares/issues/2374#issuecomment-2394028666
== secure cloud research ==
* move notes from chat to wiki
* Revamped Confidential VMs section in wiki
== RamCrypt + no-fill cache mode ==
* 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/
* Parick: minor corrections have been made. Please post.
* Posted: https://lore.kernel.org/lkml/20241003194147.2566a393@kf-ir16/T/#u
== ISO - Fix encryption checkbox bugs ==
* https://github.com/calamares/calamares/issues/2375
* https://github.com/calamares/calamares/issues/2379
* PR at https://github.com/calamares/calamares/pull/2376
== ISO - calamares encryption settings ==
* https://forums.kicksecure.com/t/iso-cryptsetup-full-disk-encryption-fde-set-more-secure-default-encryption-settings/588
* Can we use shell aliases or wrapper to influence cryptsetup default options to set strong encryption settings such as AES512 instead of only AES256?
* https://github.com/calamares/calamares/issues/1452
* or add a calamares feature so distro developers or users can configure the cryptsetup command line options in /etc/calamares
{{CodeSelect|code=
sudo cryptsetup --verbose --use-random --cipher aes-xts-plain64 --key-size 512 --hash sha512 --use-random luksFormat
}}
* 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" -
* "" - 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?
* Requires support in libkpmcore first, did research and started discussion at https://discuss.kde.org/t/making-libkpmcores-luks2-settings-more-secure/21764 to get the ball rolling
* Received no response for approximately six days, filed an MR: https://invent.kde.org/system/kpmcore/-/merge_requests/54
Patrick:
* on https://discuss.kde.org/t/making-libkpmcores-luks2-settings-more-secure/21764 please post a link to https://invent.kde.org/system/kpmcore/-/merge_requests/54
* on https://invent.kde.org/system/kpmcore/-/merge_requests/54 please post a comment such as (adjust as comfortable, after verification):
** No, /dev/random is not the same as /dev/urandom even on modern kernels. [Code Comparison - /dev/random vs. /dev/urandom](https://www.kicksecure.com/wiki/Dev/Entropy#Code_Comparison_-_.2Fdev.2Frandom_vs._.2Fdev.2Furandom)
** "cryptsetup --help" on Debian bookworm:
* aes-xts-plain64 seems to be the default indeed. The argument of not hardcoding it to automatically get safer the default in the future makes sense.
* Glad if we can get the hash size increase.
Aaron:
* Left desired notes on merge request: https://invent.kde.org/system/kpmcore/-/merge_requests/54#note_1044980
== org.freedesktop.secrets implementation ==
* https://forums.kicksecure.com/t/error-storing-passphrase-in-keyring-the-name-org-freedesktop-secrets-was-not-provided-by-any-service-files/582
* Researched and commented: https://forums.kicksecure.com/t/error-storing-passphrase-in-keyring-the-name-org-freedesktop-secrets-was-not-provided-by-any-service-files/582/2
== Cloud virtualization - research RAM-less encryption techniques for disk and RAM encryption ==
See https://www.whonix.org/wiki/Dev/cloud#Confidential_VMs
== live-build dracut test ==
* from a Debian perspective (because Kicksecure will start using it at some point) by building an ISO
* please test and notify upstream about your test results
* https://salsa.debian.org/live-team/live-build/-/merge_requests/353
* does the ISO have the "ISO - error message during boot: mount: /sysroot: special device LiveOS_rootfs does not exist" issue? (related to task below)
* Trixie and Bullseye both work well, Bookworm fails to boot with a sysroot mount failure. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082891
== ISO - error message during boot: mount: /sysroot: special device LiveOS_rootfs does not exist ==
* https://forums.kicksecure.com/t/iso-error-message-during-boot-mount-sysroot-special-device-liveos-rootfs-does-not-exist/418
* fixed in https://github.com/ArrayBolt3/derivative-maker/commit/894d0657b7cd69370d67759709fff166d469cc37
** Patrick: needs further work as discussed
** Patrick: please no modules in derivative-maker (if needed needs to be in a package)
** Patrick: please track down root cause
* Root cause found, reported at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082891
== unbootable system after installing dracut on a standard Debian installation ==
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078792
* Caused by a missing dracut dependency, "systemd-cryptsetup", see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078792#15
* Bugfix tested, works
* Merge request in Debian at https://salsa.debian.org/debian/dracut/-/merge_requests/37
== grub-live with 90overlayfs ==
* context: [[grub-live]]
* https://github.com/Kicksecure/grub-live
* https://github.com/Kicksecure/grub-live/blob/master/etc/grub.d/11_linux_live
* stop using 90overlay-root
* port grub-live to 90overlayfs
## 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: [https://github.com/dracutdevs/dracut/issues/1565#issuecomment-2378133277 Boot Existing, Usual Linux Installation from Hard Disk in Live Mode / read-only mode with dracut #1565]
== dracut - test dracut without systemd ==
* as discussed earlier
* as it might fix the issue below
* Works, implemented as https://github.com/ArrayBolt3/derivative-maker/commit/894d0657b7cd69370d67759709fff166d469cc37
** Patrick: not going for this solution (as we would be the odd distribution out not using systemd in dracut, to avoid bugs as a result of that)
** Patrick: instead merged with task [[Dev/todo#ISO_-_error_message_during_boot:_mount:_.2Fsysroot:_special_device_LiveOS_rootfs_does_not_exist|ISO - error message during boot: mount: /sysroot: special device LiveOS_rootfs does not exist]]
== kloak - memory leaks ==
* 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 ==
* https://github.com/QubesOS/qubes-issues/issues/8541
* please read
* please consider related to previous Qubes kloak work, communicate with Qubes
* consider future wayland support
* note: kloak doesn't necessarily need to run in dom0. Even if it "only" runs in a VM is a big win. Final decision is up to Qubes. This is yet to be discussed, decided.
* Added comment at https://github.com/QubesOS/qubes-issues/issues/8541#issuecomment-2377325699
== ISO - must choose encrypt vs not encrypt. Empty default setting ==
* https://forums.kicksecure.com/t/iso-no-default-for-encryption-on-off-user-should-choose-explicitly/567
* Done via https://github.com/ArrayBolt3/live-config-dist/commit/410c62e664e7d1387e7c013867242838ff2cb912
* Also discovered and offered a fix for https://github.com/calamares/calamares/issues/2375 while working on this
== kloak - update readme ==
* Please make sure compilation instructions are OK.
* Please check/fix readme.
* https://github.com/ArrayBolt3/kloak/commit/4bbdf38cc6c6f9162348d9b23deef3169f8465b8
== kloak - fix debug symbols ==
=== W: kloak-dbgsym: debug-file-with-no-debug-symbols [usr/lib/debug/.build-id/3a/ae8c705abefbd590d2206221eea4c2abd90cf4.debug] ===
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:
* ISO build giving warning about missing debug symbols, advises adding -g flag to gcc commands
* Should be resolved by https://github.com/ArrayBolt3/kloak/commit/29477f98d1192ced4fb0e630c07dbd8b97942d22
== read Dev bash wiki page ==
* https://www.kicksecure.com/wiki/Dev/bash
* 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? ==
* please try to reproduce
* comment on the ticket
* https://github.com/jirka-h/haveged/issues/81
* Doesn't appear to be an issue, tweaking the generator to output only 1s results in test failures, see https://github.com/jirka-h/haveged/issues/81#issuecomment-2372664967
== oomd ==
* please comment in case you have any useful input. otherwise nvm.
* https://forums.kicksecure.com/t/consider-installing-systemd-oomd-by-default/223
* Left comments at https://forums.kicksecure.com/t/consider-installing-systemd-oomd-by-default/223/4
== ISO - Install to system desktop icon: maximize window ==
* https://forums.kicksecure.com/t/install-to-system-desktop-icon-maximize-window/419
* Fixed with https://github.com/ArrayBolt3/live-config-dist/commit/ab8a7e1829f7050882385488a67e9a316a9270fd
== gpg sign all your future git commits ==
* similar to https://github.com/onionshare/onionshare/issues/221
* arraybolt3: enabled permanently in Git settings
== add gpg key to your github ==
* Currently in github commit history your keys still show up as unverified.
* https://docs.github.com/en/authentication/managing-commit-signature-verification/adding-a-gpg-key-to-your-github-account
* This is a personal decision for each developer. Some don't want to do it as it might cause a false sense of security letting github verify the gpg key. In case you don't wish to do that, this is OK too.
* arraybolt3: Added to Github, doesn't pose any particular problem for me.
== Add python3 dependency to mediawiki-shell package ==
* 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 ==
copy notes on seecmop debugging from https://github.com/Whonix/kloak/pull/1 to https://www.kicksecure.com/wiki/Seccomp
(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 ==
* [[Dev/audio#mod.rt:_Can.27t_find_org.freedesktop.portal.Desktop._Is_xdg-desktop-portal_running.3F|mod.rt: Can't find org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?]]
* https://github.com/Kicksecure/desktop-config-dist
* note: is a systemd user (not system) unit
* using systemd preset
== kloak - add configuration option to disable rescue key ==
* 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-2196543109
== kloak - testing ==
* test kloak
* improve documentation on testing https://www.whonix.org/wiki/Keystroke_Deanonymization#Defense_Testing
* maybe try to find additional tests (if needed) using perplexity.ai
== kloak - document rescue key ==
* https://www.whonix.org/wiki/Keystroke_Deanonymization#Kloak
* document: rescue key
* document: disable rescue key
== kloak - makefile fix ==
* Makefile should check if pkg-config exist because otherwise it fails with libevdev error?
== kloak - verbose log sharing ==
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 ==
* please confirm https://github.com/vmonaco/kloak/issues/51
== kloak - xrdp support ==
* is xrdp support conceivable?
* user reports: when using xrdp, only /dev/input/event0 is there, which does not contain real keystroke.
* This does not seem possible. xrdp is its own X server, logging keystrokes at the X server level is doable but intercepting them does not appear to be doable, see https://www.kicksecure.com/wiki/Progress_Reports?shownotice=1#Investigate_xrdp_support.
== kloak development ==
* instead of this list, does it make more sense to review pull requests, issues and rewrite in python? (Works just fine in C, rewrite not planned at this time)
* strong compile time hardening flags (done)
* goal: perfect string parsing and error handling in case of corner issues, to not break input devices (keyboard, mice) (doesn't appear that much string parsing is done, currently not considered an issue)
* check pull requests, merge if sensible
** Add a header file to make future development easier - https://github.com/vmonaco/kloak/pull/61 (done)
** Chatgpt3 https://github.com/vmonaco/kloak/pull/65 (done)
** update readme - https://github.com/vmonaco/kloak/pull/70 (specific to vmonaco's version of Kloak, not Whonix's)
** add support for new devices attached after kloak starts (needs cleanup) - https://github.com/vmonaco/kloak/pull/67 (done)
* code review with ChatGPT, claude.ai (done)
* use AddressSanitizer (aka ASan) if doable with reasonable effort and considered useful (done)
* port to C++ if considered useful (rewrite not planned at this time)
* other improvements to increase stability
** strncpy - https://github.com/vmonaco/kloak/issues/66 (done)
* fix compile time warnings if reasonable (probably already resolved by above) https://github.com/vmonaco/kloak/issues/35 (done)
* ARM support, only if doable with reasonable effort - https://github.com/vmonaco/kloak/issues/25 (done)
* fix time related keyboard stops working bug (done)
** https://github.com/vmonaco/kloak/issues/31
** Root cause analysis and potential fixes: https://github.com/vmonaco/kloak/issues/31#issuecomment-2368666686
** https://forums.whonix.org/t/sdwdate-can-cause-system-time-to-jump-backwards-causing-issue-with-kloak/20433
* All relevant issues should be solved by https://github.com/Whonix/kloak/pull/1
= Footnotes =
{{Footer}}