On Tuesday, August 4, 2020 10:38:29 AM MST Chris Murphy wrote: > On Tue, Aug 4, 2020 at 7:40 AM Martin Langhoff > <martin.langh...@gmail.com> wrote: > > > > > > > Are there options for remote-wipe features for Fedora (or RHEL for that > > matter)? > > > > > > > Ideally something integrated into the early boot process, as well as a > > persistent service that is non-trivial to tamper with. It would naturally > > need a network/internet based service as control point. > > > > > > > Googling and searching the mailing list has not turned any leads. > > > > > > > > It is a can of worms, naturally, and I am well aware of limitations, and > > tricky tradeoffs in remote-wipe schemes. For some use cases, including > > one affecting me, it can reduce attack surface. I am hoping that some > > solutions exist, I would be happy to improve, package, integrate... > > > > > > Such a thing doesn't currently exist. There are pieces here and there, > that could be tied together, or used as references: > > - livecd-tools and dracut have a reset boot parameter for the live > read-write persistent overlay. We don't use such a thing in > conventionally installed systems though.
Nothing in Fedora, except live systems, makes use of overlay filesystems. > - Silverblue/rpm-ostree and Fedora Core OS based systems have > 'rpm-ostree reset' to blow away overlays. I'm not sure if it currently > has an option to blow away user home as well as /etc and /var. If not, > it could be extended. > > - Perhaps this is something either ignition (CoreOS installer) or > systemd-repart could do? Possibly more the former than the latter, > because systemd-repart use case is more about adding, not removing, > and growing, not shrinking. > > - If you were to use 'blkdiscard' on an entire partition or drive, > doesn't mean the data is truly gone, i.e. data remanence. It might be > easier and safer to secure such data with LUKS encryption, and have a > way to wipe the key or keys. > > - There's also the concept on Android, Windows, and macOS for > "recovery" partitions and booting. These recovery partitions tend to > be read-only boots, with limited tools and interface. This could be > leveraged for multiple needs: recovery boot for doing volume rescue > and repair; it could contain the installer, capable of doing a network > (re)install; or it could even be a "seed" from which a new system is > provisioned, and made whole by e.g. 'dnf group install'. > > - Fedora has a "rescue" GRUB boot menu option. This is a "no > host-only" initramfs. Currently it's never updated, i.e. it gets > stale. For a while I've wanted us to remove this initramfs during > release upgrades, so they get regenerated. At the least it'd be nice > to make this more useful than it currently is. There's really no reason to update that initramfs frequently, it's only used for recovery, and it has everything in needed to initialize devices for boot. -- John M. Harris, Jr. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
