Does anyone use any integrity checking in Dom0

[simon....@gmail.com]

As per subject, does anyone use things such as AIDE (or other file integrity IDS) ?

I understand the security model is "if dom0 is compromised, you are fscked" but it would be at least nice to have something that gave me a heads up if such an event happens.

[unman]

On Tue, Jan 08, 2019 at 04:25:00AM -0800, simon....@gmail.com wrote:
> As per subject, does anyone use things such as AIDE (or other file integrity IDS) ?
>
> I understand the security model is "if dom0 is compromised, you are fscked" but it would be at least nice to have something that gave me a heads up if such an event happens.
>

I use tripwire - primarily in dom0, but also in selected qubes.
Also periodic rpm -aV in dom0.
As you say, always nice to know if the games up.

[799]

Hello,

Am Di., 8. Jan. 2019, 13:25 hat <simon....@gmail.com> geschrieben:

As per subject, does anyone use things such as AIDE (or other file integrity IDS) ?

I understand the security model is "if dom0 is compromised, you are fscked" but it would be at least nice to have something that gave me a heads up if such an event happens.

I was thinking about this as I am currently running a dual boot setup, which means that the /Boot partition is unencrypted and could theoretically be compromised as it unencrypted.

I have therefore written a small script which fingerprints all files in the Boot partition and verify the fingerprints later - basically something like a poor man's IDS.

The hash sume file itself is GPG signed and _not_ stored on boot but the encrypted part of dom0.

So if files in boot got changed I do get an alarm when I verify the fingerprints.

This could then lead to the decision to rebuild/drop the whole system as it could have become (reasonable) insecure.

I tried to find out if I can run the scripts before login into Qubes but it seems that there is no way to do so.

So now I have the idea that the script will run after login of dom0 and then present a notification:  boot files are ok.

- O.

[Chris Laprise]

On 01/08/2019 07:25 AM, simon....@gmail.com wrote:
> As per subject, does anyone use things such as AIDE (or other file integrity IDS) ?
>
> I understand the security model is "if dom0 is compromised, you are fscked" but it would be at least nice to have something that gave me a heads up if such an event happens.

I think Marek mentioned that HEADS has a root fs verification scheme. I
was going to try HEADS but the dependence on Google services made me
back off.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Chris Laprise]

On 01/08/2019 03:07 PM, Chris Laprise wrote:
> On 01/08/2019 07:25 AM, simon....@gmail.com wrote:
>> As per subject, does anyone use things such as AIDE (or other file
>> integrity IDS) ?
>>
>> I understand the security model is "if dom0 is compromised, you are
>> fscked" but it would be at least nice to have something that gave me a
>> heads up if such an event happens.
>
> I think Marek mentioned that HEADS has a root fs verification scheme. I
> was going to try HEADS but the dependence on Google services made me
> back off.
>

Of course, I should mention anti evil maid: AEM essentially protects the
/boot partition (and your firmware!). That is nothing to sneeze at and
gives you a decent basis for investigating the dom0 root volume if
something does crop up.

[simon....@gmail.com]

Chris Laprise wrote:

> Of course, I should mention anti evil maid: AEM essentially protects the
> /boot partition (and your firmware!). That is nothing to sneeze at and
> gives you a decent basis for investigating the dom0 root volume if
> something does crop up.

AEM wont work with one of my machines BIOS AFAIK . that bios has no legacy mode its all UEFI, so per the docs, AEM wont work.

>was going to try HEADS but the dependence on Google services made me back off.

Didnt realise there was a dependence on google services for heads. That seems counter intuitive to me. Wheres the dep?

[Illidan Pornrage]

Actually there is no dependency on google services. THere is "Google
Authenticator, but that is an open source TOTP Generator that works
without internet that can be installed on android.
BUT
There are also commandline programs for it on every major desktop distro.

Essentially for HEADS to work you need:
Coreboot working on your board.
A TPM
A persistent storage drive
A stripped down enough linux kernel for your board that fits in bios
flash memory and that can use the tpm
an initramfs for that kernel that is the actual "heads" part that does
all the magic.
A second device that shows you the current totp (time based one time
pad) to compare it with the value that heads is showing. If match then
system files and booted code are still as expected, if not investigate.
TOTP is based on a secret from which the OTPs (one time codes) are
generated via time.
So the second machine stores a secret and needs a roughly accurate time.
On the machine to be verified the secret exists only when it is booted
in the correct state and only then the passphrase should be entered. If
the booted code is different the secret is not existing instead another
secret is existing that is not the right one that generates a mismatches
that of the verifier device.
The verifier device should ideally be offline so as to not be easily
manipulated so it contains another secret that matches a modified
bootloader. I think an old android with removed/castrated radio hardware
containing a totp app would be a good candidate.

Rest assured the official tails git only contains a device config for
the Thinkpad X230 that is quite outdated.
The purism coreboot repo contains a heads fork that is compatible with
librem devices and their other fancy stuff that sadly is quite overpriced.
Porting heads to your device to be verified is a royal PITA as testing
is annoying without a spare device. Because you most certainly will
flash a whole bunch of builds that arent working yet as your bios and
then need to flash the next build or a working backup of normal coreboot
with an InSystemProgrammer which is fiddly stuff.

Been there, done that. Is a major baywatch episode of fail on the beach
and I made a cludgy half working compromise that I would be ashamed to
put anywhere near public.
I could sink insane amounts of additional time in those things but it
feels like a dead end as long as nobody pays me for my time. I cant even
guarantee success as I am not an expert in those things. I just try to
be McGyver as much as I can.

[Illidan Pornrage]

I apologize for this truckload of typos and bad formatting. Sleep
deprivation much.