Porting Tails OS to Devuan / Disclosure & Discussion Thread

thezeit · 2018-09-07 12:24:52

I've decided to start "remastering" Tails OS images to use Devuan (purging systemd & gnome in the process).

A quick leading note first: I was pointed to heads. I do have some concerns about the ways in which heads is maintained (those concerns might be outside the scope of this thread though). A combination of that + my familiarity with Tails + aleady having tools in place to remaster Tails has me embarking on this.

I'll lead with this: I'm not normally one to seek communal support on anything. However, there are some interesting facets here that I do think should be disclosed & discussed. That and I would be open to identifying areas I missed. e.g. cleaning systemd/gnome out of existing systems could result in active components being accidentally left in place.

Baking Remastered Versions of Tails OS

This part is already done and I've been doing it for a couple years now.

I have the process refined down to clean LXC containers using clean rootfs bootstraps as a sandbox to install necessary remastering tools. It's designed to be launched from Tails live-booted provided you have enough ram or (hopefully encrypted) swap.

So I'm building remastered Tails images from Tails.

The First Stab

I'm tinkering with getting qemu to boot Tails from an ext4 instead of the squashfs so that I can make changes more easily. This was a little bumpy. I have an idea but probably won't be able to follow up on it until next week.

systemd in initrd?

During the qemu boot tinkering I got dumped into busybox in the initrd rootfs a number of times.

While poking around in the process list I noticed a systemd process running in the background. The execution line looked like it mentioned something about DNS being "always off". I ran out of time and didn't get to inspect it further. But my anticipation here is that I'm going to need to rebuild a systemd-free initrd image.

Personal note: The hazards of systemd really sank in for me here. A hairball that's designed to access the internet "to make things more modern" actively alive in the initial ramdisk is a horrifying prospect. I'm left wondering what "mistakes" might exist in the systemd code that would modify the default security states of the Linux kernel.

systemd unit file porting

I looked at the Tails unit files. Most of them appear to be agnostic and basic. I spotted 3 that made reference to gnome and only 1 that actually invoked gnome directly. A quick dip into the code revealed that it ***looks*** like they query the default display manager in some places without making assumptions about what that might be.

Yes, I'm set on this, but...

While my mind is made up to poke at this pretty hard... I'm very much open to things I might be missing.

I'm anticipating getting tangled up in some of their automated menu systems that might not fire correctly.

It's also not immediately clear to me if I'll need to recompile their kernel image or if I can just hotswap the initrd. I don't have the ISO open to look at right now (am pulling this from memory from earlier).

fsmithred · 2018-09-07 21:31:16

I can think of a couple ways to approach this. If everything needed to make Tails is in the debian repos, then it's available in devuan, too. Start with a minimal install, either on hardware or a VM, then add what you want, then make a live iso (for example, by using refractasnapshot.)

The other way would be to install Tails to hardware or virtual disk, upgrade it to devuan, and again, make a live iso with refractasnapshot. I don't think Tails includes an installer, but you could install refractainstaller and install from the live session.

thezeit · 2018-09-08 01:06:33

fsmithred wrote:

I don't think Tails includes an installer, but you could install refractainstaller and install from the live session.

I've never heard of refractainstaller before. I will have to check that out.

Would you believe me if I said I already have an early migration test up and running?

Tails uses an overlay filesystem and prompts for some configuration options immediately at the login session. So you can either disable or enable root access at that prompt, etc... The problem with taking a live snapshot after passing that screen is you can't get back to it, lol! Although I've never tried sneaking around it by attempting to switch full-screen ttys there.

So, I have it booting in QEMU.

- Outer layer (normally formatted as an ISO type) as an ext4
- The internal file system (normally formatted as a squashfs type) as an ext4.

It's way easier to work on and do boot tests with now.

Just have to remember to umount the internal one before running QEMU or it'll drop into busybox.

Screenshot (hosted by a free image service):

The greeter got trampled. This is the switch to xcfe with the ASCII migration method.

I will need to check into how they've hooked the greeter to see if I can restore it.

In regards to their systemd unit files I have a script that hypothetically should allow them to be converted to sysvinit recursively. Not every bit of systemd functionality can be automatically ported with it but it doesn't look like Tails is using anything advanced in that regard. Just basic "restart this service if it dies" sort of thing.

I'm ALMOST starting to have fun.

thezeit · 2018-09-08 12:51:11

I think I figured out how this song & dance is going to go.

At /etc/gdm3/PostLogin/Default is a script. It does most of the work when first logging on.

The script itself is almost straight Linux other than it expects a few script files to potentially be created by Gnome.

It handles setting up the default user, hardening the settings, if root login should be allowed, etc...

There's a "gotcha" one level beneath that though. It calls some Tails scripts elsewhere that handle the network setup. And you guessed it! They're using systemctl & NetworkManager. It doesn't look like they're invoking anything heavily and/or sprawling though. Most of it is MAC testing with panic fallback that'll disable the network entirely.

And the other minor "gotcha" below that is it sends desktop notifications with gnome envionment settings. They use the standard notification mechanism and were pretty clean about containing the gnome environment settings to a single file. So if the gnome environment settings end up being a problem I could probably just trample that file.

So right now the first phase idea is as follows:

- Install lightdm
- Setup a lightdm greeter script that takes a few inputs
- Have that script prepare some files for the script at /etc/gdm3/PostLogin/Default and invoke
- Possibly work out kinks in desktop notificiation

The above should hypothetically get Tails ported away from Gnome and closer to lightdm.

Once the above is done then some additional steps would need to happen to knock systemd out:

- A /sbin/systemctl script may be needed to intercept systemd requests and translate them to sysvinit service requests
- Most systemd unit files will need to be ported to sysvinit scripts (automatically?)
- The rest of the Devuan migration steps would then apply here.

The final baker would probably do the above in reverse due to potential package orphaning problems. But for development & working out the kinks I'm thinking this has to be done in forward order. e.g. start by trying to get lightdm to forward to their existing scripts with systemd in place and work out desktop notifications that expect a gnome environment. Once tails is working in lightdm then the jump won't be so drastic.

Last edited by thezeit (2018-09-08 12:57:03)

thezeit · 2018-09-08 15:33:07

Have you ever wondered what Tails would look like in Xfce?

Me too!

Tails 3.9 complete with the latest Tor Browser based on Firefox Quantum.

Please hold your applause until the end.

Last edited by thezeit (2018-09-08 15:38:44)

thezeit · 2018-09-08 23:42:29

Tor network settings panel now works.

At boot you're automatically dropped into the amnesia user with root credentials of "toor".

And as soon as a network interface connection is detected the Tor network launcher fires.

A few odd chinks in the Tails design

- The tor starter in the network manager waits for an "ibus" process which is completely absent in Xfce. I had to tweak their sleepy loop to corect for this.

- A "localectl" systemd service is used to initialize the locales at session start. Will need to kick that out at some point.

- The gnome environment settings hook presumes a gnome-shell pid will be there and the network launcher fails to start if the environment code is left in its default form. I disabled the gnome references and she came right up.

At this point...

I need to streamline my tweaks into my remastering process. I have a bunch of manual edits I need to automate.

Once that's done this image should be functional. It's still systemd-dependent but removing Gnome qualifies as an upgrade.

thezeit · 2018-09-10 13:56:48

And... it's alive!

Weird Corner

Sometimes the security slider doesn't come up on the browser (onion on the left). Clearing the ~/.tor-browser folder and turning the browser back on fixed it.

The Scripts

I've omitted the surrounding remastering tools and am including the code bits to modify the rootfs.

These scripts presume your terminal is already cd'd to the base of the rootfs file system.

Excuse some of the naming conventions as I'm only including the relevant bits.

Host / DNS / Apt

NOTE: Apt sources here pointing to Debian repos until porting is fully complete. Repos are exclusive.

#! /bin/bash

#update hosts to filter dns requests
echo '#!/bin/sh

# Note: must run after /lib/live/config/0020-hostname since it
# otherwise will overwrite any hosts file generated at build time with
# a bloated one that also include the IPv6 host `::1 localhost`, which
# can lead to IPv6 traffic, which we block, which may lead to stuff
# breaking (for instance APTs tor+http transport).

echo "- setting up hosts file"
. /etc/live/config.d/hostname.conf

cat > /etc/hosts << EOF
127.0.0.1 localhost localhost.localdomain ${LIVE_HOSTNAME}
EOF' > ./lib/live/config/9000-hosts-file

#update dns resolver
echo "127.0.0.1 localhost localhost.localdomain amnesia" 		> ./etc/hosts
echo "nameserver 127.0.0.1" 						> ./etc/resolv.conf

#set permissions if not already set
chmod 644 ./etc/resolv.conf

#move the tails package updating file out of the way
mv ./etc/apt/apt.conf.d/80tails-additional-software ./etc/apt/

g_preapt="# /etc/apt/sources.list
deb tor+http://vwakviie2ienjx6t.onion/debian/ stretch main contrib
deb tor+http://sgvtcaew4bxjd7ln.onion/debian-security stretch/updates main contrib
deb tor+http://vwakviie2ienjx6t.onion/debian/ sid main contrib"

echo "$g_preapt" > ./etc/apt/sources.list

Xfce Switch

Excuse some redundant logic. Cobbling out the other remastering work.

#! /bin/bash

#chroot mounts
for f in proc sys dev ; do mount --bind /$f ./$f ; done

mount -o nosuid,nodev -t tmpfs tmpfs ./dev/shm
mount -o nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 -t devpts devpts ./dev/pts

#do chroot
cat << EOF | chroot ./

function installuser() {
	adduser \$1 --gecos ",,,," --disabled-password
}

#
# update - install xfce & lightdm
#		

export DEBIAN_FRONTEND=noninteractive

apt-get update
apt-get install xfce4 lightdm -y
dpkg-reconfigure xfce4
update-alternatives --set x-session-manager /usr/bin/startxfce4
echo "/usr/sbin/lightdm" > /etc/X11/default-display-manager
dpkg-reconfigure lightdm

#
# create some users and potentially set the root password (DEBUGGING ONLY)
#

installuser "amnesia"

#echo "root":"toor" | chpasswd
echo "amnesia":"toor" | chpasswd

passwd -d amnesia

#
# Session start hook
#

echo '#! /bin/bash

# * /etc/live/config.d/username.conf : $LIVE_USERNAME
# * /var/lib/gdm3/tails.locale : \$TAILS_LOCALE_NAME, \$TAILS_XKBMODEL,
#   \$TAILS_XKBLAYOUT, \$TAILS_XKBVARIANT, \$TAILS_XKBOPTIONS, \$CODESET
# * /var/lib/gdm3/tails.password : \$TAILS_USER_PASSWORD
# * /var/lib/gdm3/tails.physical_security : \$TAILS_MACSPOOF_ENABLED

backupdir="\$( cd "\$( dirname "\${BASH_SOURCE[0]}" )" && pwd )"

echo "TAILS_MACSPOOF_ENABLED=yes" >  /var/lib/gdm3/tails.physical_security
echo "TAILS_NETCONF=obstacle" >> /var/lib/gdm3/tails.physical_security

echo "TAILS_LOCALE_NAME=\"en_US\"" >  /var/lib/gdm3/tails.locale
echo "TAILS_FORMATS=\"en_US\"" >> /var/lib/gdm3/tails.locale
echo "TAILS_XKBMODEL=\"pc105\"" >> /var/lib/gdm3/tails.locale
echo "TAILS_XKBLAYOUT=\"us\"" >> /var/lib/gdm3/tails.locale
echo "TAILS_XKBVARIANT=\"\"" >> /var/lib/gdm3/tails.locale
echo "TAILS_XKBOPTIONS=\"\"" >> /var/lib/gdm3/tails.locale

echo "TAILS_USER_PASSWORD=toor" > /var/lib/gdm3/tails.password

backup=\$PWD
cd \$backupdir
./Default
cd \$backup

{ nohup /usr/local/sbin/tails-tor-launcher & } &
' > ./etc/gdm3/PostLogin/DefaultPorted

chmod 755 ./etc/gdm3/PostLogin/DefaultPorted

#
# auto-login at lightdm greeter
#

echo '
autologin-user=amnesia
#autologin-user-timeout=0
session-setup-script=/etc/gdm3/PostLogin/DefaultPorted
' >> ./usr/share/lightdm/lightdm.conf.d/01_debian.conf

#
# patch gnome settings
#

sed -i 's/export_gnome_env/export_gnome_env_backup/g' ./usr/local/lib/tails-shell-library/gnome.sh

echo 'export_gnome_env() {
    . /etc/live/config.d/username.conf
}' >> ./usr/local/lib/tails-shell-library/gnome.sh

#
# patch tor launcher to wait for tor process before activating panel
#

sed -i 's/until pgrep -u "\${LIVE_USERNAME}" '\''^ibus-daemon'\''/until pgrep -f "\/usr\/bin\/tor"/g' ./usr/local/sbin/tails-tor-launcher

#
# patch network manager to no longer wait for the ibus
#

sed -i 's/if pgrep -u "\${LIVE_USERNAME}" '\''^ibus-daemon'\''/if pgrep -u "\${LIVE_USERNAME}" "bus-daemon"/g' ./etc/NetworkManager/dispatcher.d/01-wait-for-notification-recipient.sh
EOF

umount ./dev/shm
umount ./dev/pts
for f in proc sys dev ; umount ./$f ; done

Personal

Wow!

The UI is so fast now things are loading before I have time to think.

The Gnome UI would always stick and sometimes freeze with certain apps hitting certain points. Killing the apps with a fullscreen tty was the only way to get Gnome back in some cases. The majority of the rest of the time required alt+tab to unstick the Gnome windows. And with the latest Firefox Quantum.. when launched the browser would sit, and sit, and sit under Gnome until becoming responsive after a minute or two. It's now responsively almost immediately under Xfce.

Something that's really been bugging me under Tails is that Gnome would just outright crash and the whole display would reset. This was happening loosely under Tails 2~ when being prompted by Thunderbird. They had a help ticket open for it and were "deferring to upstream" to fix the problem... hoping it would be fixed by the time Debian Stretch arrived. Guess what? It's worse under Stretch. Now Gnome crashes more often with more apps more frequently.

I've actually had people get annoyed with Tails and stop using it because of how "sticky" the UI was. I became accustomed to it because I liked the other rootfs hardening. Now with the system moving like lightning... I'm the slowest link in the chain! And yes... we're going to pretend that metaphor makes sense.

Last edited by thezeit (2018-09-10 14:01:37)

blinkdog · 2018-09-12 04:32:41

This is pretty cool stuff.

Do you have a repository where you are tracking this work?

thezeit · 2018-09-12 22:02:22

blinkdog wrote:

This is pretty cool stuff.
Do you have a repository where you are tracking this work?

I do not. I would like to but... I admittedly have an aversion to the possibility of repo tampering (e.g. Microsoft owning github now).

I've oft thought it would be amazing to have a git repo backed up by Freenet so that it's essentially tamperproof (i.e. mods only possible by people with crypto keys). Someone tried awhile back and there's some code floating around for it. I unfortunately might be a tad short on time to play with too many cool things like that.

thezeit · 2018-10-03 18:00:28

I have been testing Xfce steadily under normal conditions since the last post.

I bumped into two major things:

- Xfce sometimes (rarely) will freeze completely. Not sure if that's Xfce itself or something else.

- When having windows that are redrawing their graphics on a background workspace the other workspaces can completely freak out graphically. Visual tearing appears and if you drag a window around it "wipes" the workspace back to how it should look. But as soon as a background window (on another workspace) redraws something it freaks again. This isn't always consistent behaviour and the odds of reproduce increase with the more windows that are open. This creates an issue of either not using background workspaces and/or limiting the number of open windows.

The last one almost makes my normal "power use" unworkable.

Any suggestions on an alternative window manager?

Ideally something that's as fast as Xfce without the visuals freaking under power use.

Last edited by thezeit (2018-10-03 18:01:04)

golinux · 2018-10-03 18:14:46

I have been using Xfce for over 5 years and never had either of these problems. I have 7 desktops running with 3/4 different browsers going at all times. I often do extensive graphical, audio and video editing and will keep those windows in and out of suspend for days/weeks at a time. The only "freezing" issue I have ever had is with firefox - no surprise there. xkill fixes that with one click. I use the nouveau driver and it works well with intel graphics.

I'd start by checking every option under the window manager settings. But it sounds like more of a graphics driver issue to me. Could also be lack of hardware resources. I just impulse ordered another 4GB RAM last night.

thezeit · 2018-10-17 01:43:24

Thanks for the tips!

I'll give it a play. Come to think I haven't stress tested on all but one machine...

It flares up really bad when I use a screen recorder. Everything that was stable goes suddenly unstable. The graphics driver didn't even occur to me. I'll have a play on different hardwares before I go kicking Xfce too hard.

Webtyro · 2018-11-13 15:44:57

golinux wrote:

I have been using Xfce for over 5 years and never had either of these problems.
The only "freezing" issue I have ever had is with firefox - no surprise there.

Same here with firefox and my Xfce desktops. I know Github is comped but Pyllyukko has a user.js
for hardening Firefox you may want to check out. Copy/Paste from his settings is pretty safe.
You can easily go over his settings. I also set "trr mode to 5" to turn off DNS use by Firefox.
Not sure when they may enable that on their own.
I do find Xfce very stable over the years.

The officially official Devuan Forum!

#1 2018-09-07 12:24:52

Porting Tails OS to Devuan / Disclosure & Discussion Thread

#2 2018-09-07 21:31:16

Re: Porting Tails OS to Devuan / Disclosure & Discussion Thread

#3 2018-09-08 01:06:33

Re: Porting Tails OS to Devuan / Disclosure & Discussion Thread

#4 2018-09-08 12:51:11

Re: Porting Tails OS to Devuan / Disclosure & Discussion Thread

#5 2018-09-08 15:33:07

Re: Porting Tails OS to Devuan / Disclosure & Discussion Thread

#6 2018-09-08 23:42:29

Re: Porting Tails OS to Devuan / Disclosure & Discussion Thread

#7 2018-09-10 13:56:48

Re: Porting Tails OS to Devuan / Disclosure & Discussion Thread

#8 2018-09-12 04:32:41

Re: Porting Tails OS to Devuan / Disclosure & Discussion Thread

#9 2018-09-12 22:02:22

Re: Porting Tails OS to Devuan / Disclosure & Discussion Thread

#10 2018-10-03 18:00:28

Re: Porting Tails OS to Devuan / Disclosure & Discussion Thread

#11 2018-10-03 18:14:46

Re: Porting Tails OS to Devuan / Disclosure & Discussion Thread

#12 2018-10-17 01:43:24

Re: Porting Tails OS to Devuan / Disclosure & Discussion Thread

#13 2018-11-13 15:44:57

Re: Porting Tails OS to Devuan / Disclosure & Discussion Thread

Board footer