SolidHal
Consider Kicksecure
Kicksecure is a Debian derivative distro focused on security. It's an offshoot of Whonix (i.e. the Whonix features that are security-focused are now maintained as part of Kicksecure, with Whonix now being a Kicksecure derivative that adds the anonymity-focused features). Kicksecure can be installed via distro-morphing, i.e. you can start with a Debian system, run an apt install command, and end up with a Kicksecure system.
I've briefly tested distro-morphing PrawnOS to Kicksecure, and I can confirm that it works fine. It would be interesting to consider making PrawnOS support installing the Kicksecure packages as part of the installation procedure, which would improve the UX of Kicksecure considerably compared to the current workflow of installing PrawnOS and then manually distro-morphing to Kicksecure.
One potential decision that would need to be made is whether the Kicksecure packages should always be included in the PrawnOS images (with the user choosing whether to use Kicksecure on the install step), or if it should be an optional build-time flag (like the choice of Debian suite is now). The advantage of the latter is that it would avoid increasing the size of the non-Kicksecure images, but the advantage of the former is that there would be fewer images needed, and the user wouldn't need to commit to a decision when downloading the image.
Thoughts?
I would have to look into the advantages kicksceure brings before considering the work of maintaining both a debian and kick secure release. Might be as simple to point the build system at a different sources.list
I would have to look into the advantages kicksceure brings before considering the work of maintaining both a debian and kick secure release. Might be as simple to point the build system at a different sources.list
@SolidHal It's a little bit more complex than pointing at a different sources.list, because Kicksecure uses Debian's repos for most packages, and only adds some extra packages via the Kicksecure repo (not unlike how PrawnOS works). One of the Kicksecure packages also tweaks the Debian sources.list to enable some extra security features (mostly related to TLS and Tor) that aren't in the default sources.list. But, that said, it's mostly pretty straightforward, and integration would look something like this:
- On image build, add an extra file to
sources.list.dthat contains the Kicksecure repo. - On image build, pre-download the Kicksecure CLI and XFCE packages (pretty sure there's just one metapackage that depends on all the others, so this is easy).
- On install, if the user is using XFCE, install the Kicksecure XFCE packages that were pre-downloaded; otherwise install the Kicksecure CLI packages.
- Finally, delete the default
sources.listthat Debian came with, since Kicksecure installs its own replacement insources.list.d.
In terms of work involved for you: I currently use a custom home-rolled setup that closely resembles Kicksecure (or the Kicksecure derivative Unistation [1], which would also be useful to have available in PrawnOS), and I'd really like to switch to PrawnOS + Kicksecure/Unistation on my C201. As such, I'm probably fine with writing the code that integrates this stuff (it's not going to be a lot of code), and I'm also probably fine with sending PR's your way to fix things whenever I notice something is broken. If it's a feature that's not considered officially supported, i.e. "code is present for it, but isn't regularly tested by PrawnOS devs", that's still fine for me, and it'll hopefully help some other people too.
That said -- Kicksecure and Unistation are both very cool from a security and privacy standpoint, and I think they're a good fit given that PrawnOS also cares about those things. So I certainly hope you'd be a fan of them. :)
[1] Unistation is basically like Whonix, i.e. an anonymity-focused Kicksecure derivative, except that the "gateway" and "workstation" are running on the same system instead of 2 separate VM's. So it has a tad less isolation than Whonix, but works on hardware without HVM (such as the C201) and uses much less RAM (also useful on the C201).
EDIT: And FWIW I'm totally fine with making this stuff disabled by default and only activated by a build-time env var, like the non-buster suite support, if that makes it less of a bother for you.
@JeremyRand having it be a build time variable makes the most sense to me. If you throw some PRs my way, I might be interested in "officially" supporting a kickesecure based build once I play with it myself :) Even if I'm not interested in "officially" supporting them, I'll definitely merge them in.
Adding a DISTRO_BASE envar that defaults to debian, but can be specified like the TARGET envar I added for arm64 support, to switch to kicksecure/unistation would likely offer the most flexibility.
whatever you decide to do, I'll be happy to see it :)