Remote wipe options for Fedora?

[Martin Langhoff]

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...

regards,


martin
-- 
 martin.langhoff(a)gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted        ~  http://github.com/martin-langhoff
   by shiny stuff

[Michel Alexandre Salim]

Hi Martin,

On Tue, 2020-08-04 at 09:40 -0400, Martin Langhoff 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. 
>   
I'm not aware of one myself, though I am interested if one exists (and
am contemplating writing one if none does).

I have a potentially easier use case in that I can assume disks are
encrypted with LUKS, and so removing all the LUKS keys and rebooting
the machine would lock out anyone in possession of the machine anyway.

One possible approach is to just write an MDM (Mobile Device Management
- sic) client for Linux, since there are open source MDM servers like
micromdm - https://github.com/micromdm/micromdm

Best regards,

-- 
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2

[Chris Murphy]

On Tue, Aug 4, 2020 at 7:40 AM Martin Langhoff
<martin.langhoff(a)gmail.com&gt; 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.

- 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.


--
Chris Murphy

[John M. Harris Jr]

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.langhoff(a)gmail.com&gt; 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.