Re: Thoughts on GuixSD and IDS like AIDE and Tripwire

[dian_cecht@zoho.com]

On Sun, Jan 01, 2017 at 06:56:09AM +0000, Pjotr Prins wrote:
> Yes, you can do a challenge build. Not all builds are fully
> deterministic yet, so you there will be conflicts. I use guix publish
> on a server, so I can compare the stores on two machines for
> comparison which ought to be identical. That is a pretty fast way to
> do it provided they are not both compromised ;)

Can other people access these servers for comparisons? That could be rather
useful, especially if your email was published somewhere and random people could
check their stores against yours (or anyone else who wanted to make that data
available).

> At the moment we don't store hashes in a database for the contents of
> a build tree. I think it is a good idea to have the option to create a
> tripwire-like database at build/install time, almost for free,
> provided the user moves that database off-site for later (fast)
> comparisons. It can actually speed up challenge builds.

Being able to publish said database would be even more useful, even just pushing
it to some pastebin site for people to download and compare could be useful so
that everyone could see what is going on and (could) help improve security
everywhere since you A) aren't hoping upstream isn't compromised (one of
the advantages of source-based distros imo), B) are able to compare local builds
with others (with the obvious exception of nondeterministic builds. These should
probably warn a user when they are installed, if they don't already), and C)
can compare your local store to others just so you can tell if something
funny/hacky/virusy is going on.

I'd imagine it would be reasonably trivial to simply checksum the contents of
the store during the install phase, then output the checksums into a database
somewhere for people to use. Once that is supported, an external script[1]
could be used to compare two database files, and if said script and/or Guix
could generate a new checksum database on command, then you have a rather
cheap AIDE/Tripwire system built in with little to no additional code or cost.

> I used to run tripwire a lot, but somehow have become
> confident in my security setup (rightly or wrongly so). At least with
> Guix I know I can quickly rebuild a new system that behaves as the
> compromised one. That makes me happy.

In my opinion, IDSs fail on desktop systems because of the fairly constant
influx of updates we (should) get. Constantly running and rebuilding a database
is a hell of a chore (especially since the database for an IDS should be stores
off the system itself, probably on a flashdrive or SD card or the like), and
especially massive updates can cause problems (mainly by hiding an undesired
change in the system in a sea of legit changes from the update).

P.S. On second thought (and after a cup of coffee), could the database file be
generated using the same format programs like md5sum, sha1sum, et al use so we'd
just have to run (for example) md5sum -C database?

[1]. I think an external script would be safer here than entirely relying on
Guix for this kind of functionality. The main reasons mostly boil down to
auditability and, if simple enough, even being reasonably trivial to duplicate
in other languages. There is also the option of using a minimal enviroment to
store this script somewhere safe, such as including it in a rescue LiveUSB or,
depending on how full-featured GuixSD's initramfs is, in the initramfs itself.