Trying to morph Kicksecure on Debian Bullseye

Hello,

I have a barebones Debian Bullseye install (no graphical desktop) and get the following error when trying to install kicksecure-xfce:

Preparing to unpack …/651-kicksecure-xfce_3%3a23.7-1_all.deb …
Unpacking kicksecure-xfce (3:23.7-1) …
Errors were encountered while processing:
/tmp/apt-dpkg-install-vvzm66/504-security-misc_3%3a22.9-1_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

In the docs for chroot installation of kicksecure, the option “SECURITY_MISC_INSTALL=force” is mentioned.

Is that something that needs to be implemented here?

For example:

sudo DEBDEUG=1 apt install --no-install-recommends kicksecure-cli

Instead of the “normal” installation command. This is to gather debug output.

It shows the bash xtrace (each and every command executed) during package installation.

Hello Patrick, thank you for taking time!

We use Whonix and just want to help the community by making the Kicksecure ISO with live-build on debian.

So there are many errors…

This happens in chroot stage of live-build.

Simple config:

#!/bin/sh

set -e

lb config noauto
–distribution bullseye
–architectures amd64
–debian-installer live
–debootstrap-options “–include=apt-transport-https,apt-transport-tor,openssl”
–archive-areas “main contrib non-free”
–apt-recommends true
“${@}”

I tried 2 ways.

1.) adding kicksecure repository + key in config/archives and kicksecure-xfce package in config/package-lists.

2.) adding repository via echo and installing kicksecure-xfce as chroot.hook

Both have the same errors unfortunately.

/var/lib/dpkg/info/tzdata.postinst: 32: cannot create /dev/null: Permission denied

Preconfiguring packages …
/tmp/keyboard-configuration.config.DESJTU: 38010: cannot create /dev/null: Permission denied
/tmp/keyboard-configuration.config.DESJTU: 38050: cannot create /dev/null: Permission denied
/tmp/keyboard-configuration.config.DESJTU: 37946: cannot create /dev/null: Permission denied
/tmp/keyboard-configuration.config.DESJTU: 38775: cannot create /dev/null: Permission denied
/tmp/keyboard-configuration.config.DESJTU: 38781: cannot create /dev/null: Permission denied
/tmp/keyboard-configuration.config.DESJTU: 37879: cannot create /dev/null: Permission denied
/tmp/locales.config.uHpoca: 547: cannot create /dev/null: Permission denied
/tmp/locales.config.uHpoca: 566: cannot create /dev/null: Permission denied
/tmp/locales.config.uHpoca: 570: cannot create /dev/null: Permission denied

/var/lib/dpkg/info/python3.9-minimal.postinst: 20: cannot create /dev/null: Permission denied
/var/lib/dpkg/info/python3.9-minimal.postinst: 21: cannot create /dev/null: Permission denied
/var/lib/dpkg/info/python3.9-minimal.postinst: 22: cannot create /dev/null: Permission denied
/var/lib/dpkg/info/python3.9-minimal.postinst: 26: cannot create /dev/null: Permission denied
/var/lib/dpkg/info/python3.9-minimal.postinst: 27: cannot create /dev/null: Permission denied
/var/lib/dpkg/info/python3.9-minimal.postinst: 28: cannot create /dev/null: Permission denied
/var/lib/dpkg/info/python3.9-minimal.postinst: 31: cannot create /dev/null: Permission denied
/var/lib/dpkg/info/python3.9-minimal.postinst: 43: cannot create /dev/null: Permission denied

The above errors I am not sure about. The install script probably pipes something to /dev/null, but the permission denied makes no sense to me.

Preparing to unpack …/0250-sgml-base_1.30_all.deb …
/var/lib/dpkg/tmp.ci/preinst: 17: cannot create /dev/null: Permission denied
dpkg: error processing archive /tmp/apt-dpkg-install-GrKGGP/0250-sgml-base_1.30_all.deb (–unpack):
new sgml-base package pre-installation script subprocess returned error exit status 2
Selecting previously unselected package libsysfs2:amd64.

Adding group sysfs' (GID 110) ... Done. Adding group cpuinfo’ (GID 111) …
Done.
Adding user root' to group sudo’ …
Adding user root to group sudo
Done.
Adding group console' (GID 112) ... Done. Adding group console-unrestricted’ (GID 113) …
Done.
Adding user root' to group console’ …
Adding user root to group console
Done.
/var/lib/dpkg/tmp.ci/preinst: line 200: /dev/null: Permission denied
/var/lib/dpkg/tmp.ci/preinst: line 211: /dev/null: Permission denied
/var/lib/dpkg/tmp.ci/preinst: line 59: /dev/null: Permission denied
/var/lib/dpkg/tmp.ci/preinst: ERROR: No user is a member of group ‘sudo’. Installation aborted.
/var/lib/dpkg/tmp.ci/preinst: ERROR: You probably want to run:

sudo adduser user sudo
sudo adduser user console

This I understand. Because their is no user account during chroot stage it cannot be added to the groups so root is used instead. I could get around this by adding random user with “adduser username1” and then later using --bootappend-live “…user=username1”

Errors were encountered while processing:
/tmp/apt-dpkg-install-GrKGGP/0250-sgml-base_1.30_all.deb
/tmp/apt-dpkg-install-GrKGGP/0895-security-misc_3%3a22.9-1_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Thank you for your interest!

That won’t be simple at all. There’s no shortcut to a proper ISO build process. Won’t be live-build based.

It was previously contributed for Whonix:

But it’s unfinished. Previously that code managed to create a Whonix-Host ISO. Adjustments are probably needed to make it build a Kicksecure ISO. Help is welcome but it requires development skills.

Will be live + calamares installer. (calamares integration source code already included in the project source code.)

I have also faced the same and worked on this -

Disable Autostart

Usually not required. Highly discouraged. May be useful for offline (vault) VMs.

1. Platform specific notice.

  • Kicksecure ™ for Qubes: In Template.
  • Kicksecure ™: No extra steps required.

2. Run the following command.

sudo systemctl disable sdwdate

3. Done.

Autostart of sdwdate has been disabled. Sdwdate will not be started after reboot.

4. Optional. Consider [disabling sdwdate-gui autostart].

Perhaps at a later time, perhaps after a test reboot, the user might consider to disable .

sdwdate Design

Server Authentication

only connects to Tor onion services, which are encrypted by default and do not rely on SSL certificate authorities (CAs). Three different pools are used for time sources so that if too many connections fail for any given pool, the pool is considered as potentially compromised and sdwdate aborts.

sdwdate Source Pools

Determining what sources should be trusted is an important issue; this is also a problem with NTP.

The sdwdate pools used by Kicksecure ™ are based on stable and reliable Tor onion service web servers. The pools are listed in
The various onion services are categorized into three different pools. Any member in one pool should be unlikely to share logs (or other identifying data), or agree to send fake time information, with a member from the other pools. In basic terms, sdwdate picks three random servers - one from each pool - and then builds the mediate (middle position) of the three advertised dates.

sdwdate is only using ‘pal’ pools and not relying on ‘neutral’ and ‘foe’ pools as per tails_htp, because a good rationale for that approach has not yet been provided.

sdwdate Time Sources Criteria

Current Implementation 1.0

Prerequisite knowledge:

These criteria are meant to be fitting the dynamic trust of the internet and to be as close as possible to the highest trustable level.

Time Source Inclusion Criteria

  • Trustworthy. This criteria probably means many different things for many different people. To clarify, it needs to be compatible with the. Trustworthy as far as infrastructure goes, for example as in unlikely to be using cloud and/or insecure hosting for receiving confidential documents.
  • Hosted by non-anonymous organizations or persons.
  • Reachable over an .onion domain.
  • If there is a forced redirection from (non-TLS) http onion to TLS https onion, the TLS certificate must be valid.
  • Highly likely to be hosted on different hardware than other sdwdate time source pool members.
  • Onion v3.
  • Must be a “real” onion service. Must not redirect to clearnet.

Details:

It is required that each sdwdate time source pool member has both, a clearnet domain name and an onion domain name. An example of a clearnet domain name is kicksecure.com. An example of a onion domain name is w5j6stm77zs6652pgsij4awcjeel3eco7kvipheu6mtr623eyyehj4yd.onion. The clearnet domain must be reachable [TLS] with a valid TLS certificate. This is because when a website is reachable over .onion which has a corresponding clearnet domain name with the same contents, hosted by the same author, its easier to verify the identity of the website author, when the website was created, where the website or its maintainers are located.

There needs to be evidence that that onion domain is hosted by the same author as the clearnet domain. This can be a mention of the onion domain on the clearnet domain or the [Onion-Location HTTP header]. The latter can be conveniently noticed by visiting the website using Tor Browser and then showing onion available and seen by using services such as securityheaders.com or using the curl command line tool, i.e. curl --head https://clearnet.domain.

Onion services likely hosted on the same hardware or by the same author will be grouped together and act as one. I.e. these will be considered mirrors of the same onion. sdwdate picks one mirror from the group randomly. Any onion from that author will not be used more than other pool members. The load among these grouped pool members will therefore be load balanced.

Reasons:

This provides higher certainty of having trustworthy time source members because these websites and services services have a reputation to maintain. This includes for example e-mail services such as protonmail or big news network like The Guardian and so on. Note: Just because these are known organizations and very hard to make them operate maliciously that doesn’t mean there are guarantees whether by mistake, hacks or by outside pressure.

Unrealistic Time Source Criteria

  • The onion service being popular or receiving great amount of traffic. This is very hard to verify, compare as outsider and reason about. Also (very) high traffic onion services might be less reliable.

Suggestions for sdwdate time sources

  • [Time Source Inclusion Criteria]
  • New sdwdate pool member additions must be proposed in public in Kicksecure ™ development forum thread to allow anyone to comment on it.
  • Please check the suggested onion was already previously suggested by searching the forum thread.
  • Please try to avoid suggesting onions which are already included in [/etc/sdwdate.d/30_default.conf git master]

Rules for sdwdate time source related git pull requests[edit]

  • [Suggestions for sdwdate time sources]
  • the following type of changes need to be proposed separately using separate pull requests
    • removal of sdwdate pool members because these are offline, unreliable, their clock is too much off or otherwise no longer comply with the requirements
    • updates to already existing sdwdate pool members
      • such as updated onion domain names in case the onion domain name change
    • additions of new sdwdate time sources (if there where no objections in previous forum discussion)

Time Sources Exclusion Criteria

The rationale for the following exclusion criteria is to avoid likely insecure websites and also to avoid any mention whatsoever of controversial content within sdwdate source code.

The following categories must be avoided and deleted if turning out later so:

  • onion v2 since deprecated.
  • Unstable Website: It is not useful to add a service which is periodically unavailable.
  • Sold Out Website: It is better to remove websites there recently sold out with major content changes to be expected.
  • Website Went Offline: If the website went offline then it should removed.
  • Contain Any Form of Pornographic Content.
  • Contain or Encourage on Damaging Human Health: like drugs, alcohol, smoke, etc.
  • Contain Any Form of gore, gangs, terrorist, assassination Content.
  • Contain Deanonymization or Cracking Services or Spying Agencies: like or the NSA, GCHQ, etc.
  • Contain or Related to Any Form of Governmental Website: like ministries or military websites or anything similar. Basically here I am working or to attach morph to my mobile app development company server side. (Specially those which end with .gov.)
  • Draw highly controversial attention to Kicksecure ™ or sdwdate due to their on-site or off-site activities.
  • Websites which Kicksecure ™ as default software sources (such as Debian) or potential other purposes. This is because, should there be any issues with these services (such as being down for maintenance or other issues such as being under a denial of service attack) this should not break multiple things in Kicksecure ™ such as sdwdate and APT upgrading at the same time.

Comment Field Rules

The sdwdate configuration format for onion sources is:

onion.onion # web.archive.org-link-with-evidence-onion-belong-to-corresponding-clearnet-domain optional-clearnet-link optional other comments

Or:

onion.onion # archived-link-with-evidence-onion-belong-to-corresponding-clearnet-domain mandatory-clearnet-link optional other comments

The part of the the hash ("#") for each pool member is shown in sdwdate logs as comment.

The first part of the comment must be an archived link that confirms that the onion link belongs to the organization. I.e. is not an anonymous mirror, impersonating link, fake or scam. If using web archive nothing else is required. Clearnet domain in the comment field is optional since for links that are archived on web archive it is trivial to extract the unarchived link from the web archive link.

If links are archived with archivers other than web archive then after the archived links there must be a space and the unarchived clearnet link.

After that there can be another space and additional comments.

In doubt just look at the many existing examples in and imitate new entries.

This is useful so users, reviewers can more easily see in sdwdate logs which organizations where used during sdwdate time fetching since it is hard to remember and/or cumbersume to look up that belongs to or cumbersome to manually look up every time.

Confirmation that onions belong or at least did belong to a specific organisation is possible can be done either manually by opening the archived link and looking if it mentions the corresponding onion or assisted with the script.

/usr/share/sdwdate/onion_test_confirm

Contributor Proposed Version 2.0[edit]

It is being proposed to drop the requirement hosted by non-anonymous organizations or persons. I.e. onion’s hosted by anonymous organizations or persons should also be permitted under the following conditions.

  • Here things are little bit more trickier as we cannot know much except what the website claiming to be so we cannot know who, where, how long etc. this website was running. So we need verification mechanism to check:
    • Consensus or Aggregation of Testimonies: We try to collect users opinions on this website and thus clearnet will be heavily involved into this specially in social media and blogs. So we can verify this website is really doing what it claims to be doing. For example, an e-mail service claiming to not spam their users should not spam their users.
    • Seniority: The older a website becomes, the more trustworthy it will be considered if there have not been any (deliberate or by mistake?) public verifiable breaches of its promises. Recently established websites cannot be with reasonable certainty considered well tested, established, being scam, fraud, deception or not.

sdwdate checks if dates/times from remote servers (onions) are within Tor consensus/valid-after and consensus/valid-until date/time, otherwise rejects those. An example from sdwdate log.

2021-01-09 14:47:17 - sdwdate - INFO - * consensus/valid-after: 2021-01-09 13:00:00 2021-01-09 14:47:17 - sdwdate - INFO - * remote_time : 2021-01-09 14:49:38 2021-01-09 14:47:17 - sdwdate - INFO - * consensus/valid-until: 2021-01-09 16:00:00 2021-01-09 14:47:17 - sdwdate - INFO - * time_consensus_sanity_check: sane

sdwdate Time Replay Protection

Done in testers repository master. Will flow to stable as per usual.

sdwdate internally uses

Effectively, sdwdate looks at file /usr/share/timesanitycheck/minimum_unixtime which contains a minimum unixtime timestamp which was created by developers during development and file /var/lib/sdwdate/time-replay-protection-utc-unixtime which will be created every time after sdwdate has successfully set the time. sdwdate will not set time earlier than the time in these files. The purpose of this is to implement Time Replay Protection. No matter if sdwdate onion servers later give false time information due to a bug or an attack to users, the clock would never be set to a much earlier date such as year 1980 or an earlier date than the release date.

File /usr/share/timesanitycheck/minimum_unixtime will be occasionally updated by developers. It is planned to update that file at least for every release. Whenever /usr/share/timesanitycheck/minimum_unixtime was updated. [Time Attacks] thorough false time source replies against sdwdate with times before that time will not be possible.

Most users users it should not be required however users are free to create a custom extra file /etc/minimum-unixtime or /usr/local/etc/minimum-unixtime which sdwdate would also honor and never set the clock earlier than that time. All minimum unixtime files would be considered.

sdwdate could optionally also be instructed to ignore vendor provided file /usr/share/timesanitycheck/minimum_unixtime, sdwdate auto generated file /var/lib/sdwdate/time-replay-protection-utc-unixtime and above mentioned user custom extra file by by creating a custom override file /etc/minimum-unixtime.override (lower priority) or /usr/local/etc/minimum-unixtime.override (higher priority) which take absolute priority and result in ignoring all other minimum unixtime files. Valid values in any minimum unixtime files are only integer values. Example: 1611651349. Minimum value is 0 which however does not make sense except for testing purposes. That would effectively disable time replay protection. For testing purposes it might be useful to set a far future date such as 2611651349 which could be temporarily enabled to test if sdwdate’s time replay protection would be functional.

sdwdate Clock Randomization

Log example.

End fetching remote times. pool differences, sorted: [-35, 5, 5] median time difference: +5.000000000 randomize : -0.976225329 new time difference : +4.023774671

The rationale for that is that an onion time source could try to tag specific users. sdwdate uses the median time (not average) fetch result. (Average time of the 3 pools would not be be safe. To explain, suppose one pool returning a result of -1000 seconds time difference would overpower the time pools with a more realistic time difference of for example -1 and -2 seconds.)

Let’s say the normal distribution for most users would be pool differences, sorted: [7, 5, 3]. Then and onion time source could experiment with saying 4, 5, 6 to split users into different groups. This is assuming that not too many users ask the same server at the very same time. A realistic assumption given that the total number of Tor users is not that high. By adding up to ± 1 second it gets harder to tag specific users.

After boot, sdwdate sets the time using the date after fetching times from remote.

  • Without clock randomization: The command executed from sdwdate could be sudo date --set "Tue 12 Jan 2021 06:48:55 AM UTC". This allows for more opportunities to tag user because nanoseconds are to 0 without any randomization. The full command to be run could be guessed by the sdwdate time source. Or might change from
    • old unixttime: 1610866967.519335985 to
    • new unixtime : 1610866966.519335985.
  • With clock randomization: The command executed from sdwdate could be sudo date --set "Tue 12 Jan 2021 06:48:55:976225329 AM UTC". Only the first part of the date/time Tue 12 Jan 2021 06:48:55 AM UTC can be guessed but an an extra random clock skew is introduced. The random nanoseconds part 976225329 being unpredictable by remote time sources.

(These are just examples. sdwdate internally actually uses unixtime since that is easier in the program. Just to illustrate the mode of operation.)

If nanoseconds are randomized and later leaked to for example remote web servers, it won’t be possible for the remote web server know if clock is just skewed normally or if it was set using sdwdate with randomization. Rationale of randomization is making it look more like a naturally skewed clock.

Accuracy of sdwdate is far outside of ± 1 second anyhow. Due after asking a remote onion web servers for the time and the result being relayed back through the slow Tor network to the user with hard to predict latency, nanoseconds might not matter anyhow. By the time sdwdate running date, nanoseconds might already be randomized without extra randomization required.

When supposing for the sake of threat modeling that a web server can observe clock jumps from remote because of lets say browser, javascript or something leaks it is better to jump to a randomized number of nanoseconds 976225329 than 000000000.

Hope this will help everyone.

Please do not copy whole wiki pages to the forums. It’s confusing because it’s not clear if any changes were made and getting more confusing in the future.

Please delete / edit / repost or something.