subgraph / citadel Goto Github PK

Wat do? Should I stop checking back? Do you need funding? Governments intimidating you? Did you just get bored? If you properly open source the code, we might be able to continue where you left off...

A set of iptables rules need to be added to Citadel to not allow any access to the network at all from components running inside Citadel. Some exceptions will exist of course, such as the dhcp client.

Not only should all network access be blocked but it must be logged as well so that we can investigate any component that believes that it needs to do something on the network.

Of course the user will want to be able to use the internet so application image instances will need to be permitted to reach the network. Currently the nspawn containers are just using the simplest networking option and sharing the host network namespace. The plan I'm proposing is to configure them with Veth interfaces instead, and assign those interfaces to a bridge named something like 'clearnet'. Later when VPNs are supported, we can manage assigning application images to the correct network context by just adding them to the appropriate bridge.

When running nm-connection-editor in Sway, attempting to change the wifi settings will generate an error message indicating that there are insufficient privileges to "initiate the (wifi config) editor". Underneath this, PolicyKit is rejecting the authorization:

error time=1522021521.370256 sender=:1.4 -> destination=:1.209 error_name=org.freedesktop.Net
workManager.Settings.PermissionDenied reply_serial=11
   string "Insufficient privileges."

This operation does succeed in GNOME on CItadel.

The workaround is to su in Citadel terminal and run nm-connection-editor, which one would expect to not work but does. Or to configure the wifi network in GNOME first.

Gnome changes the timezone by sending requests over the org.freedesktop.timedate1 dbus interface which is implemented by systemd-timedated.

systemd-timedated reads and changes the timezone by expecting a symlink /etc/localtime to exist and point to a subdirectory of /usr/share/zoneinfo/. There is not any flexibility to change where to find the /etc/localtime symlink, it's hardcoded into systemd and the code will not follow additional symlinks.

I don't see a way to fix this without patching systemd, and least intrusive patch would be to just replace the path /etc/localtime with /storage/citadel-state/etc/localtime.

> make citadel-image
docker run -it --mount type=bind,source=/Users/user/citadel,target=/home/builder/citadel citadel-builder   bash -c "source setup-build-env && bitbake citadel-image"
Error: TEMPLATECONF value points to nonexistent directory '../meta-citadel-distro/conf'
make: *** [citadel-image] Error 1
>

I dropped into a shell and it is indeed missing and doesn't appear to exist anywhere within the container.

Modifications are required in the gcc/gcc-cross and citadel-kernel recipes in relation to getting GCC plug-ins to compile with GCC 8.x.

As the root filesystem in Citadel is read-only, the password file also cannot be changed. If the password file was made mutable with a bind mount or by symlinking into /storage, then it could be used for persistent code execution in Citadel by altering the shell field.

Ideally, it should also be possible to change this password from inside running application images and to keep the application image user password synchronized with the lockscreen password.

The solution I'm proposing is to use pam_userdb for authentication of only the the user account both in citadel and inside the application image and to RW bind-mount the database inside the application container.

slurp is a tool for selection regions for taking screenshots in Sway. There is currently a problem where slurp cannot load the cursor theme for the crosshair cursor. This will cause slurp to crash:

citadel:~ $ slurp
slurp: ../git/main.c:459: main: Assertion `cursor' failed.
Aborted (core dumped)

Prior to the crash, the following call is made:

wl_cursor_theme_load(NULL, 24 * output->scale, state.shm);

NULL would normally contain the cursor theme name, which falls back to default if not specified. There is no default theme path in Citadel. However, on other systems that lack the default theme path, this call will find the configured theme instead of falling back to the default theme. So it is possible that there is something different in Citadel that is causing the problem -- so I am recording the bug here before taking it to the slurp developer. I don't expect the cursor lookup failure in Wayland will cause problems for other things but it would be cool to make it work for slurp.

Workaround

The workaround is to copy the crosshair cursor to a path that the Wayland cursor theme loading routines expect. The following paths are expected:

/home/citadel/.icons/default/cursors/
/usr/share/icons/default/cursors/
/usr/share/pixmaps/default/cursors/
/home/citadel/.cursors/default/cursors/
/usr/share/cursors/xorg-x11/default/cursors/
/usr/share/icons/default/cursors/

An example of how to do this (note: since /home/citadel is a tmpfs, this will not persist after rebooting):

citadel:~ $ mkdir -p /home/citadel/.icons/default/cursors/
citadel:~ $ cp /usr/share/icons/Paper/cursors/crosshair .icons/default/cursors/

Investigate what Radeon extra firmware needs to be added both to initramfs and rootfs

There is a meta-amd layer for Yocto, and Debian has a package just for Radeon firmware.

Putting the kernel modules on the rootfs means that the rootfs can only be used with the exact same kernel version.

They should be moved to the /storage partition and either secured with kernel module signing or placed in a resource pack (see #5)

Resource Packs are ext2 formatted disk image files, similar to the rootfs image files. Rather than being written to a disk partition they are loopback mounted and contain metadata which describes how to bind mount the internal contents over the rootfs file tree.

Similar to how the rootfs file images are managed, the resource pack images are secured with a signed dm-verity hash.

This feature will solve a couple of important problems:

1. The rootfs currently contains some very large packages containing things that will rarely or never need to be changed.

• 68MB: /lib/firmware
• 55MB: Icon theme
• 19MB: Desktop background images
• 13MB: Adapta Gtk/Gnome theme
• 15MB: Locale data only for one locale (en_US)
• ... and possibly more

2. Due to requirement of keeping the rootfs image as small as possible, we cannot include multiple locales. Also we have carefully chosen what looks like the most important firmware, then cross our fingers and hope everybody's hardware will work.

Having this feature will allow us to support things like extra language packs, and allow pretty much any custom configuration that anybody could want on top of the base rootfs image.

Gnome terminal built for Citadel should be patched to have a unique application id so that it does not conflict with the gnome terminal instance in the application image.

It would be nice to have an easy way to enable a writable tmpfs overlay mounted on the rootfs. This would would simply development workflow, but also it would be a good tool to detect components that are silently failing to write to the read-only filesystem. The system could be run for a while with this overlay enabled and then the upperdir can be examined for unexpected files. I think it's highly possible that some components will just fail to write files without generating any log messages and that these failed writes could result in subtle breakage that would be very hard to otherwise track down.