clipos / bugs Goto Github PK

• Add strongSwan
• Harden strongSwan systemd unit
• Add automatic test infrastructure using a Debian virtual machine

Good morning, everyone,

I think it would be interesting to add the following hardenings:

1. Symlinkown
2. S.A.R.A
3. TPE-LSM or TPE-without-LSM
4. Hardened defconfig
5. Vmware PAX, PAX_NOWRITEEXEC, PAX_EMUTRAMP, PAX_MPROTECT
6. Vmware PAX_RANDKSTACK
7. Vmware rap_plugin can be used with a gcc patch.

There is no difficulty to maintain on the longterm version of linux 4.19.

Best regards,

After some testing, we realized that Firmware based TPM 2.0 as found into some Intel chips does not support the TPM 2.0 functionnality we currently use. We should thus add support for current discrete TPM 1.2 devices to enable support for current generation of hardware still in production use.

• Add TPM 1.2 tools to efiboot
• Update TPM Dracut boot script to detect the TPM version and act accordingly
• Update the documentation to remove fTPM mentions and update 1.2 support
• Evaluate if the testbed can provide emulated TPM 1.2

Good morning, everyone.

First of all, thank you for your work and the release of sources. I currently have a compilation problem (clean installation of GNU/Linux).

Expected Behavior

source toolkit/source_me.sh
 [*] Setting up a "toolkit" virtualenv...
     Please be patient as this may take some time on the first run.
 [!] Virtualenv setup has failed.
     Please read the log in "run/virtualenv_setup.log" at repo root level.

Actual Behavior

cat run/virtualenv_setup.log
Looking in indexes: 
Looking in links: file:///home/loic/clipos/assets/toolkit
Collecting alabaster==0.7.11 (from -r /home/loic/clipos/toolkit/requirements.txt (line 9))
  Url 'alabaster/' is ignored. It is either a non-existing path or lacks a specific scheme.
Exception:
Traceback (most recent call last):
  File "/usr/lib/python3.7/tarfile.py", line 1643, in gzopen
    t = cls.taropen(name, mode, fileobj, **kwargs)
  File "/usr/lib/python3.7/tarfile.py", line 1619, in taropen
    return cls(name, mode, fileobj, **kwargs)
  File "/usr/lib/python3.7/tarfile.py", line 1482, in __init__
    self.firstmember = self.next()
  File "/usr/lib/python3.7/tarfile.py", line 2287, in next
    tarinfo = self.tarinfo.fromtarfile(self)
  File "/usr/lib/python3.7/tarfile.py", line 1092, in fromtarfile
    buf = tarfile.fileobj.read(BLOCKSIZE)
  File "/usr/lib/python3.7/gzip.py", line 276, in read
    return self._buffer.read(size)
  File "/usr/lib/python3.7/_compression.py", line 68, in readinto
    data = self.read(len(byte_view))
  File "/usr/lib/python3.7/gzip.py", line 463, in read
    if not self._read_gzip_header():
  File "/usr/lib/python3.7/gzip.py", line 411, in _read_gzip_header
    raise OSError('Not a gzipped file (%r)' % magic)
OSError: Not a gzipped file (b've')

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/loic/clipos/run/toolkit/lib/python3.7/site-packages/pip/_internal/basecommand.py", line 228, in main
    status = self.run(options, args)
  File "/home/loic/clipos/run/toolkit/lib/python3.7/site-packages/pip/_internal/commands/install.py", line 291, in run
    resolver.resolve(requirement_set)
  File "/home/loic/clipos/run/toolkit/lib/python3.7/site-packages/pip/_internal/resolve.py", line 103, in resolve
    self._resolve_one(requirement_set, req)
  File "/home/loic/clipos/run/toolkit/lib/python3.7/site-packages/pip/_internal/resolve.py", line 257, in _resolve_one
    abstract_dist = self._get_abstract_dist_for(req_to_install)
  File "/home/loic/clipos/run/toolkit/lib/python3.7/site-packages/pip/_internal/resolve.py", line 210, in _get_abstract_dist_for
    self.require_hashes
  File "/home/loic/clipos/run/toolkit/lib/python3.7/site-packages/pip/_internal/operations/prepare.py", line 310, in prepare_linked_requirement
    progress_bar=self.progress_bar
  File "/home/loic/clipos/run/toolkit/lib/python3.7/site-packages/pip/_internal/download.py", line 824, in unpack_url
    unpack_file_url(link, location, download_dir, hashes=hashes)
  File "/home/loic/clipos/run/toolkit/lib/python3.7/site-packages/pip/_internal/download.py", line 729, in unpack_file_url
    unpack_file(from_path, location, content_type, link)
  File "/home/loic/clipos/run/toolkit/lib/python3.7/site-packages/pip/_internal/utils/misc.py", line 581, in unpack_file
    untar_file(filename, location)
  File "/home/loic/clipos/run/toolkit/lib/python3.7/site-packages/pip/_internal/utils/misc.py", line 514, in untar_file
    tar = tarfile.open(filename, mode)
  File "/usr/lib/python3.7/tarfile.py", line 1589, in open
    return func(name, filemode, fileobj, **kwargs)
  File "/usr/lib/python3.7/tarfile.py", line 1647, in gzopen
    raise ReadError("not a gzip file")
tarfile.ReadError: not a gzip file

Steps to Reproduce the Problem

1. Fresh install of Manjaro Linux x86_64
2. Installation of the recommendations and nothing else.

Specifications

• Version: clip-os 5 Alpha
• Platform: Manjaro Linux 17.1.11
• Subsystem: toolkit

• Create generic units or daemon for arbitrary tunnel and network namespace configuration
  • Dynamic network setup (DHCP & DNS) over IPsec
• Add network namespace for physical interfaces to remove all network access by default
  • Bridge physical network interfaces as workaround for XFRM interface restrictions
• IPv6 support
• Test infrastructure improvements:
  • DNS & DHCP served over IPsec for clients

Good morning, everyone,

I successfully tested the 5 alpha version, but I admit I was disappointed in the lack of the graphical environment presented at the SSTIC 2015.

Is it possible to provide us with an "unofficial and outdated" version of clipos 4, this version using linux-4.9.x-unofficial_grsec whose patches seem functional. This will allow people to easily test and better understand the work you have done.

If it is impossible to make a qemu or iso image available, will it be possible to create documentation to compile version 4?

I am grateful to you for the release of your sources. This request is not intended to bother you, it is just a request from someone very interested by this project.

Thanks. Best regards,

Specifications

• Version: clip-os 4 with linux-unofficial_grsec

• Atomic, in-background and non-intrusive upgrade mechanism using A/B partitions (similar to Android or ChromeOS)
• Fallback version available in case of unpredicted failure or bug
• Update transport protection: Transport using TLS 1.2 or 1.3 only, with pinned root CA certificate.
• Update integrity protection and verification: Signed updates using minisign.

• Choose between:
  • USB direct passthrough to a virtual machine
  • USB handling and partition mounting in the Core, to make the content accessible to a virtual machine using for example a CIFS file system (see QEMU support)

Core changes

• Choose between rsyslog, syslog-ng, etc. This choice should preferably be based on a factual comparison with security taken into account.
  • Most major Linux distributions are using rsyslog.
• Harden the daemon's systemd unit.
• Harden the daemon's configuration.
• Select which options may be changed at runtime by the system administrator.

Testing infrastructure

• Sample configuration for the QEMU test target.
• Script to provision a remote test server.

• Enable TPM support in OVMF
• Enable TPM support in the Linux kernel
• Setup encryption (dm-crypt/dm-integrity) for core & core-state partitions
• Setup unattended partition unlock with TPM backed secret sealing

See https://github.com/bus1/dbus-broker/wiki

• Update upstream Gentoo ebuild to the latest stable version
• Replace dbus with dbus-broker

Daniel Micay has created a hardened memory allocator, hardened_malloc, which provides substantial protection from memory corruption vulnerabilities.

It would be best if this was used globally by default (either by integrating it into libc or via /etc/ld.so.preload), but it can be used on a case-by-case basis via LD_PRELOAD.

From https://github.com/clipos/src_platform_updater/blob/master/TODO.md:

• Split network processing into an unprivileged process
• Reduce updater privileges
• Incremental updates using casync
• Support updating the bootloader
• Add free disk and free LV space checks
• Improve failure detection and fallback support
• Once an update is completed, inform the user that a reboot is required
• Test reporting and server-side channel selection via HTTP headers (machine-id & version)
• Improve tests and add failure test cases
• Add limited protection against DoS

Expected Behavior

Click on "Quick Try" link should open page
https://discuss.clip-os.org/t/nightly-builds-are-now-available/65

Actual Behavior

but this link does not succeed to open.
This is a severe bug because the title "Quick Try" hints this is the easy way.
If this is the easy way, do you think other ways will be harder to follow (will I try something else before try to test another part of the website or of clip os if this basic initial step is corrupt)?
I want to warn you about the evaluation of Clip OS quality (it includes documentation quality); this bug leads to a 0 quality on a scale 0-10 because it shows to a new curious user that

1. the web site have not been tested
2. the user role of Clip OS have not been taken in consideration by the dev team (who will try an os when the first step for using it fails before any step started)
3. testers professionals have not been hired in the project team (these kind of bug is the first any tester can find about a use case of a new evaluator can enter).

Steps to Reproduce the Problem

1. open in a web browser (firefox for instance) https://docs.clip-os.org/;
2. click on link "Quick Try";
3. wait for page to load (long time waiting until timeout).

Specifications

• Version: https://docs.clip-os.org
• Platform: Any Debian GNU/Linux or Devuan fork from Debian
• Subsystem: firefox web browser 60.9.0esr

Running toolkit/source_me.sh returns the following error while installing just on Ubuntu 18.04.1. Installing executable-path manually didn't solve the issue for some reason.

Installing collected packages: cosmk
  Found existing installation: cosmk 0.1.0
    Uninstalling cosmk-0.1.0:
      Successfully uninstalled cosmk-0.1.0
  Running setup.py develop for cosmk
Successfully installed cosmk
  Installing just v0.3.12
error: failed to compile `just v0.3.12`, intermediate artifacts can be found at `/media/clipos/run/cargo/target`

Caused by:
  no matching package named `executable-path` found
location searched: registry `https://github.com/rust-lang/crates.io-index`
required by package `just v0.3.12`

Specifications

• Version: n/a
• Platform: Ubuntu 18.04.1
• Subsystem: toolkit

Hi Clip-OS Team,

first of thanks for open-sourcing this interesting project. Its time qubes gets a reasonable alternative that does more than "it all runs in xen".

I've setup my dev laptop with Ubuntu 18.04 and followed the instructions. Most everything runs fine.
The first major problem I encountered was 18.04 shipping libvirt version 4.0, while 4.5 or above is required. I then found this ppa: https://launchpad.net/~jacob/+archive/ubuntu/virtualisation, which ships 4.7, so I installed it.
After some more debugging I am now stuck with:

$ sujust qemu
[...]
libvirt: error: internal error: Could not start 'swtpm'. exitstatus: 1, error:
  [x] Uncaught unknown exception libvirtError:
       internal error: Could not start 'swtpm'. exitstatus: 1, error:
error: Recipe `run` failed on line 26 with exit code 1
error: Recipe `qemu` failed on line 36 with exit code 1
error: Recipe `qemu` failed on line 24 with exit code 1

I'm not really sure how to debug this / where to find a relevant logfile. The error message doesn't give me the hint I was looking for.

I have to admit I was "debugging" for a while and may have "shot" my dev system in the process.. I could try a reinstall and start from scratch.

What distro do you guys use for development / on which system did you try things to write the doc?

Btw starting sujust qemu works without the PPA, but the image wont boot correctly complaining that libvirt is to old and that it does not support swtpm below 4.5 (if I remember correctly).

Expected Behavior

Qemu image should start without errors.

Actual Behavior

sujust qemu fails with error above.

Steps to Reproduce the Problem

1. Setup fresh 18.04
2. Install the ppa for libvirt 4.7
3. Follow steps in the doc

Specifications

• Version: 5.0 alpha
• Platform: Ubuntu 18.04
• Subsystem: Not sure what that means

This is a never closed ticket to track ongoing work on kernel update and maintenance (includes config updates and patches porting effort to the latest stable kernel release). Specific feature development will have their own tracking issue. LTS kernel maintenance will have its own tracking issue.

• 5.0
  • 5.0.5
  • 5.0.6
  • 5.0.7
• 4.20
  • 4.20.5
  • 4.20.6
  • 4.20.11
  • 4.20.14
  • 4.20.17
• 4.19
  • 4.19.11
  • 4.19.14
  • 4.19.15
  • 4.19.16
  • 4.19.17
  • 4.19.18
• 4.18
  • 4.18.13
  • 4.18.14
  • 4.18.15
  • 4.18.16
  • 4.18.17
  • 4.18.18
  • 4.18.19
  • 4.18.20

• Initial network layout using network namespaces:
  • ipsec0 network namespace with exclusive access to IPsec network
  • XFRM interface for IPsec support
• Initial static nftables-based firewall setup for all network namespaces:
  • Strict network access (input & output) controls
  • IPsec awareness
• IPv4 only support
• Testbed infrastructure update

Remove the ability for systemd-boot to load arbitrary configuration settings from a file stored in the EFI partition (see "loader.conf" contents hardcoded in "/products/clipos/efiboot/bundle.sh").
This is an issue since such a file would not be measured by the system/TPM for integrity and may change the EFI binary behavior to produce unexpected or unsafe result.

• Set default config at compile time to avoid unprotected on-disk config
• Build using the values currently set in products/clipos/efiboot/bundle.sh
• Disable configuration parsing support in systemd-boot

There is a typo in the documentation at the following URL https://docs.clip-os.org/toolkit/build.html#activate-the-toolkit-environment in the chapter SDK

The command line written in the doc is

$ sujust products/clipos/sdk/bootstrap-from-sratch in stead of

$ sujust products/clipos/sdk/bootstrap-from-scratch.

Scratch is not well written.

• Add a new LV in the main VG
• Enabled encryption and integrity for this LV using LUKS & TPM
• Make this device available during bootup

First thanks, happy that french concurrent to qubes-os and subgraphos finally coming :)

Expected Behavior

Get runc running?

Actual Behavior

I have correctly /dev/urandom on my archlinux host related to https://www.openssl.org/docs/faq.html but I get this error.

Any idea?

...
dracut: *** Stripping files ***
dracut: *** Stripping files done ***
dracut: *** Store current command line parameters ***
dracut: *** Creating image file '/boot/EFI/Linux/linux-4.17.19-r2-clipos.efi' ***
dracut: Using UEFI kernel cmdline:
/usr/bin/dracut: line 1779: warning: command substitution: ignored null byte in input
dracut: root=/dev/mapper/verity_core_5.0.0-alpha.1 rootfstype=squashfs rootflags=ro rd.lvm.vg=mainvg rd.verity.device=/dev/mainvg/core_5.0.0-alpha.1 rd.verity.name=verity_core_5.0.0-alpha.1 rd.verity.roothash=55d012293d5836fa1f04af16bd14e2dd6034526796be037d99d8dd1185672be5 rd.verity.hashoffset=122826752 rd.verity.fecoffset=123805696 slub_debug=F pti=on extra_latent_entropy iommu=force spectre_v2=on spec_store_bypass_disable=seccomp
dracut: *** Creating UEFI image file '/boot/EFI/Linux/linux-4.17.19-r2-clipos.efi' done ***
 [-] 'clipos/sdk' configures recipe 'clipos/efiboot', runs:
       {{repo}}/products/{{product}}/{{recipe}}/configure.d/96_secure_boot.sh
 [*] Sign dracut bundled EFI binary...
warning: data remaining[16188416 vs 16196886]: gaps between PE/COFF sections?
warning: data remaining[16188416 vs 16196888]: gaps between PE/COFF sections?
dataFinal failed
140695629929216:error:24064064:random number generator:SSLEAY_RAND_BYTES:PRNG not seeded:md_rand.c:547:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html
140695629929216:error:04088003:rsa routines:RSA_setup_blinding:BN lib:rsa_crpt.c:235:
140695629929216:error:04066044:rsa routines:RSA_EAY_PRIVATE_ENCRYPT:internal error:rsa_eay.c:407:
 [X] Command 'runc run --bundle /home/cyril/library/src/clipos/run/containers/clipos-sdk.configure.clipos-efiboot.q0s9h4yd clipos-sdk.configure.clipos-efiboot.q0s9h4yd' failed.
     Reason of failure: Returned exit value 1 (SystemCommandError)
error: Recipe `configure` failed on line 34 with exit code 1
error: Recipe `efiboot` failed on line 16 with exit code 1
error: Recipe `clipos` failed on line 12 with exit code 1

Steps to Reproduce the Problem

1. sujust all

Specifications

• Version: alpha
• Platform: up to date archlinux
• Subsystem:

❯ uname -a
Linux 4.17.10-1-apparmor #1 SMP PREEMPT Mon Sep 10 09:15:20 CEST 2018 x86_64 GNU/Linux
                                                                                                                                                                                                                                                
❯ openssl version
OpenSSL 1.1.1  11 Sep 2018

• Add firmware microcode ebuilds
• Dracut config

• Unprivileged admin & audit users
• admin:
  • will be able to edit some files in the state configuration folder (none for now)
• audit:
  • can read all system logs (group systemd-journal)
• Accessible:
  • over the network: using OpenSSH & key based auth only (over IPsec only will come later)
    • Remote root access for debug

• Add KVM hypervisor host configset for the Linux kernel configuration
• Add support for virtio drivers only
• Add QEMU support
  • virtio drivers only (as much as possible)
  • Harden QEMU compilation as much as possible
• Create a systemd unit to run a QEMU instance :
  • under an unprivileged user
  • with only access to the IPsec network
  • with only RW access to a specific LV device

Hello!

First of all, thanks for this cool project!

I'm working to introduce some of your kernel hardening recommendations
into the kconfig-hardened-check project.

I have a question about CONFIG_X86_MSR.
It provides access from the userspace to the x86 MSRs via char devices.
Does the kernel really need it for mitigating X86 CPU bugs?

Thanks!

Core changes

• Choose between chrony, ConnMan, ntpd, OpenNTPD, systemd-timesyncd, etc. (for a non exhaustive list, see https://wiki.archlinux.org/index.php/System_time#Time_synchronization). This choice should preferably be based on a factual comparison with security taken into account.
  • chrony is currently the preferred choice. This is based on the following security evaluation: https://www.coreinfrastructure.org/blogs/securing-network-time/.
• Harden the daemon's systemd unit:
  • Must not run as root, etc.
  • NTP traffic must transit inside an IPsec tunnel
• Harden the daemon's configuration:
  • NTP packet authentication must be enabled
  • the default servers from the ntp pool must not be used
• Select which options may be changed at runtime by the system administrator.

Testing infrastructure

• Sample configuration for the QEMU test target.
• Sample configuration to provision the remote test server:
  • NTP traffic must transit inside an IPsec tunnel
  • NTP packet authentication must be enabled

• Add a network management graphical interface for unprivileged user in the Core
• This interface should only be able to manage the Core physical interfaces and not the IPsec tunnels

In the file products/clipos/sdk_debian/receipe.toml file, the rootfs file path is hardcoded with a generation date :

rootfs_archive = "{{repo}}/assets/debian/rootfs-2018-07-27.tar.xz"

Then if the debian rootfs has been generated, the file path is different and it's impossible for the qemu/bundle target to find the rootfs :

~/clipos$ ls assets/debian/
cache  rootfs-2018-10-07.tar.xz

~/clipos$ sujust products/clipos/qemu/bundle
just ../sdk_debian/all
 [X] Uncaught unknown exception FileNotFoundError:
     [Errno 2] No such file or directory: '/home/ptitoliv/clipos/assets/debian/rootfs-2018-07-27.tar.xz'
error: Recipe `bootstrap` failed with exit code 1
error: Recipe `sdk` failed on line 11 with exit code 1

Workaround is to change manually the root path in the receipe.toml file.

As told in the documentation it is needed to force the PATH of the local user in order to have the correct path when using sujust.

I was thinking it would be maybe better to do it only when using the sujust alias with such a command :

alias sujust='sudo -E --preserve-env=PATH env PATH=$PATH:/sbin:/usr/sbin just'

Tested on a Debian sid with success.

• Test with real hardware
• Use keyctl in order to directly store the decrypted LUKS key in a kernel keyslot so that cryptsetup can use it without it being passed through userspace
• Use different PCR lists for a given machine's first boots following/during its provisioning, as we may for instance change its BIOS configuration.
• Select cryptographic algorithms based on the ones supported by the TPM

• Find a good remote desktop client (tigerVNC, remina, etc.) with support for:
  • Wayland on the client side
  • Xorg and Wayland on the server side
• Find good Xorg or Wayland servers for cages / container environments (wayvnc, etc.).

I think clip-os could use a community chat.

I'm not sure if this (the bug tracker) is the right place - if not please let me know where I can post this and close this issue.

Expected Behavior

I can join the community chat room and chat about clip-os awesomeness and problems.

Actual Behavior

I'm stuck with the github issue tracker

Steps to Reproduce the Problem

1. Search for clip-os community chatroom.
2. Only find the github issue tracker.

Howto fix

I would like if we would not use slack or any other proprietary thingy for this. I would like to propose to do this in #clip-os on freenode (IRC). What do you guys think?

CLIP OS system administrators (the admin user) should be able to change a subset of firewall setting for each cage. The main features are per cage incoming and outgoing port filtering.

• System daemon for network namespace and firewall management:

  • Network namespace setup (ipsec0, etc.)
  • nftable rules loading in each network namespace

• Dynamic firewall support with template based rulesets:

  • Templates for each cage stored in RO Core
  • Variables for each cage store in RW State

As we do not have a Python interpreter in the Core, we can not use or improve firewalld for such a feature and must thus develop our own solution.

Update config and port patches to the latest stable kernel release.

• Add an unprivileged user to Core
• Enable auto-login for this user

• [ ]
• [ ]
• [ ]
• [ ]

Expected Behavior

Actual Behavior

Steps to Reproduce the Problem

Specifications

• Version:
• Platform:
• Subsystem:

• Add a Wayland compositor to the Core (likely candidate: Sway)
• Add a permanently displayed status bar (likely candidate: Waybar)
  • Replicate CLIP OS v4 style in Waybar
• Add feature toggle to enable graphical desktop (probably in config.toml, yet to be determined)

• Setup CI (repo) and enable nightly builds (see GitLab CI pipelines)
• Provide build artifacts at files.clip-os.org

A kernel config specialized for better security inside virtual machines is in development.

The development preview version can be found here:
https://github.com/Whonix/hardened-kernel/blob/master/usr/share/hardened-kernel/hardened-vm-kernel

This work is being done by @madaidan who also contributed pull requests to linux-hardened.

https://github.com/anthraxx/linux-hardened/pulls?utf8=%E2%9C%93&q=author%3Amadaidan

Discussions about the kernel config happen mostly in Whonix forums.

https://forums.whonix.org/t/kernel-recompilation-for-better-hardening/7598/214

The hardened kernel config was contributed by @madaidan to the @Whonix project but as the maintainer of Whonix I think that it is not the most suitable project to maintain a kernel config. It would be more impactful and would get more eyes on it if it was hosted here.

Therefore I am wondering if there is any chance you would accept a pull request for a hardened VM config file? Which folder would be suitable for such a config file?

@madaidan is also working on a hardened bare metal (i.e. non-VM) kernel config:
https://github.com/Whonix/hardened-kernel/blob/master/usr/share/hardened-kernel/hardened-host-kernel

Hello!

The CLIP OS documentation about the kernel configuration has a mistake.
The CONFIG_X86_VSYSCALL_EMULATION option is called CONFIG_X86_VSYSCALL_EMULATE there: https://docs.clip-os.org/clipos/kernel.html#configuration

Could you please fix the name of this option? Thanks!

Best regards,
Alexander

• Develop or integrate an existing configuration agent that can pull configuration files or values from a remote endpoint over HTTPS & IPsec and apply those configuration changes dynamically to a running system.
• This agent will be unprivilged (!root) and run under the admin user & group

In order to install and provision a lot of CLIP OS systems at the same time, we need an automated installer, started over PXE or iPXE.

Required functionality

Server

• PXE or iPXE server to serve the installer image
• HTTPS server to serve profiles and system images
• Server to serve secrets (certificates for IPsec, etc.) and receive escrow keys (backup LUKS passphrase).

Installer

• Installer image build from a standard Linux distribution (Debian preferred) with tools pre-installed
• Automatic hardware profile discovery
• Automatic partitioning
• LUKS escrow key generation or derivation using entropy potentially provided by the server
• State partition configuration pulled from server
• Secrets installation

The current "work-in-progress" installation script is available in those two Gerrit change sets: 1 2.

See https://docs.clip-os.org/clipos/roadmap.html#multi-level-environment-support

• Add graphical user login manager for users
  • Required: Wayland and Wayland session support
  • Nice to have: support for network management
  • Nice to have: support for Kerberos based (sssd) login
• Daemon and systemd unit hardening
• Keep CONFIG_FB and CONFIG_VT enabled in kernel config only for instrumented or non-graphical builds, and document why (see this)

Expected Behavior

A correct botstrap

Actual Behavior

Unpacking source...
/var/tmp/portage/sys-apps/systemd-238-r100/temp/environment: line 1500: git: command not found
ERROR: sys-apps/systemd-238-r100::clipos failed (unpack phase):
Can't clone /mnt/src/external/systemd.

Steps to Reproduce the Problem

1. source toolkit/source_me.sh
2. (toolkit) $ cp toolkit/instrumentation.toml.example instrumentation.toml
3. sujust all

Specifications

• Version: sys-apps/systemd-238-r100
• Platform: Linux
• Subsystem: Debian

• QEMU image creation improvements:
  • Use host libguestfs directly or via a container with podman/Docker
  • Remove Debian based SDK
• Rewrite cosmk in Go/Rust:
  • Avoids issues related to Python virtual environments
  • Distribute pre-built binaries as CI artifacts
• Remove --privileged access to /dev
  • Replace squashfs based container images by OCI images managed by podman/Docker
• Remove sudo/root dependency:
  • Use rootless/unprivileged containers with user namespace
  • Rootless CI builds
• Build and pull SDK container images from the CI

• User credentials (passwords) are split from system ones (/etc/passwd, etc.)
  • RO/RW split using nss-altfiles
  • Or pam-tcb like management
• Allow unprivileged admin & audit password change
• Install time password setup
• Restrict password usage to local console access only

• Add hardware profiles to Core:
  • QEMU/KVM
  • Lenovo x260
• Hardware profile selection at install time using symlink setup in Core state partition:
  • /etc/modules-load.d/hardware.conf -> /mnt/state/core/etc/modules-load.d/hardware.conf
  • /mnt/state/core/etc/modules-load.d/hardware.conf -> /usr/share/clipos/hardware-profiles/kvm-guest/hardware.conf for QEMU/KVM
• Move hardware profiles to standalone repo, together with kernel configsets
• Support per profile firmware list

CLIP OS systems may be accessed and managed remotely using SSH over the an IPsec tunnel. However, managing a large fleet of systems this way will be cumbersome and prone to errors. Thus we need an automated agent that can automatically and regularly pull the latest configuration and apply it to the running system. In short, we need an 'rsync with signature checks' functionality.

Design

The current CLIP OS updater design 1 & 2 may serve as a basis for such an agent

Server

• HTTPS server hosting static configuration and cryptographic signatures

Client

• HTTPS client
• Care must be taken to keep file and directories ownership and access mode
• Will run under an unprivileged user (admin)

Additional requirements

• Assess if such a program already exists
• Preferred languages: Rust, Go, C, C++