Thoughts on GuixSD and IDS like AIDE and Tripwire

Thoughts on GuixSD and IDS like AIDE and Tripwire

[dian_cecht]

Hello everyone,

     I have been giving GuixSD some thought as the holiday's pass and I had a
question I wanted to ask. During a recent scare with a computer on my LAN being
compromised (a Windows system), I've been giving thought to some issues with
securing desktops, and one of those is file integrity wrt unsolicited/undesired
modification. Naturally (which may point out my general inexperience with this
kind of thing) I thought of things like AIDE and Tripwire, and gave some thought
to how such system (which are hash-based, iirc) could possibly be useful to help
recover a system from a break-in (given the hash records aren't available
locally), which brings us back to one of GuixSD's goals of deterministic builds.

     I seem to recall that there was some goal to be able to check each other's
builds by comparing hashes of builds via some currently unknown method (I think
GNUnet was going to be the transport medium, but I'm not entirely sure if that
was a serious plan or what), and while that is certainly interesting for
checking to make sure a build completed properly or that a build is in fact
deterministic (and, by extension, that there isn't an obscure bug in someone's
CPU ala Pentium Floating Point bug from ages past), I had given some thought
about all of this in relation to IDSs. Has anyone given any thought to possibly
compiling and distributing a checksum list ala AIDE (GPLed, fwiw) or Tripwire
(GPL as well) for use with GuixSD systems. While this certainly isn't a complete
solution for an IDS (in fact, I havn't even looked yet to see how feasible this
is with the aforementioned software; this is more a thought experiment than
anything), if feels like it might be something useful, which is why I'm
mentioning it here.

Re: Thoughts on GuixSD and IDS like AIDE and Tripwire

[Pjotr Prins]

On Sat, Dec 31, 2016 at 05:28:14AM -0800, dian_cecht@zoho.com wrote:
> Hello everyone,
> 
>      I have been giving GuixSD some thought as the holiday's pass and I had a
> question I wanted to ask. During a recent scare with a computer on my LAN being
> compromised (a Windows system), I've been giving thought to some issues with
> securing desktops, and one of those is file integrity wrt unsolicited/undesired
> modification. Naturally (which may point out my general inexperience with this
> kind of thing) I thought of things like AIDE and Tripwire, and gave some thought
> to how such system (which are hash-based, iirc) could possibly be useful to help
> recover a system from a break-in (given the hash records aren't available
> locally), which brings us back to one of GuixSD's goals of deterministic builds.
> 
>      I seem to recall that there was some goal to be able to check each other's
> builds by comparing hashes of builds via some currently unknown method (I think
> GNUnet was going to be the transport medium, but I'm not entirely sure if that
> was a serious plan or what), and while that is certainly interesting for
> checking to make sure a build completed properly or that a build is in fact
> deterministic (and, by extension, that there isn't an obscure bug in someone's
> CPU ala Pentium Floating Point bug from ages past), I had given some thought
> about all of this in relation to IDSs. Has anyone given any thought to possibly
> compiling and distributing a checksum list ala AIDE (GPLed, fwiw) or Tripwire
> (GPL as well) for use with GuixSD systems. While this certainly isn't a complete
> solution for an IDS (in fact, I havn't even looked yet to see how feasible this
> is with the aforementioned software; this is more a thought experiment than
> anything), if feels like it might be something useful, which is why I'm
> mentioning it here.

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 ;)

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.

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.

Pj.
-- 

Re: Thoughts on GuixSD and IDS like AIDE and Tripwire

[dian_cecht]

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.

Re: Thoughts on GuixSD and IDS like AIDE and Tripwire

[Ludovic Courtès]

Hi!

dian_cecht@zoho.com skribis:

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

That sounds like a good idea to complement ‘guix publish’ + ‘guix
challenge’.

A simple way to dump the database is like this:

--8<---------------cut here---------------start------------->8---
$ sudo sqlite3 /var/guix/db/db.sqlite
SQLite version 3.14.1 2016-08-11 18:53:32
Enter ".help" for usage hints.
sqlite> select path,hash from validpaths;
/gnu/store/98xcn26354r70nyamkgywqzjxvw3qikx-guile-2.0.9.tar.xz|sha256:a475e4bad3d39a94f01c590f239e80dbd84688e480ca74de3e335f6f36a0d975
/gnu/store/hyh7kwkqlxc0x9s8cs5mjnih5v524486-make-impure-dirs.patch|sha256:d697a02be5fea425ac93eb650b1359e3e8053d84f70677c8c0a80291ed03585e
/gnu/store/hv15hq91vm3ajv23lkq0kgd56d4kmd08-findutils-absolute-paths.patch|sha256:c4fc83e01a7f448b598905bcf6ca39b5ba0f1f0f131145b379f0de9c2fbe109b
[…]
--8<---------------cut here---------------end--------------->8---

(Of course you have to trust the database to contain the right hashes in
the first place.)

Ludo’.

Re: Thoughts on GuixSD and IDS like AIDE and Tripwire

[dian_cecht]

On Mon, Jan 02, 2017 at 11:28:55PM +0100, Ludovic Courtès wrote:
> Hi!
> 
> dian_cecht@zoho.com skribis:
> 
> > 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?
> 
> That sounds like a good idea to complement ‘guix publish’ + ‘guix
> challenge’.
> 
> A simple way to dump the database is like this:
> 
> --8<---------------cut here---------------start------------->8---
> $ sudo sqlite3 /var/guix/db/db.sqlite
> SQLite version 3.14.1 2016-08-11 18:53:32
> Enter ".help" for usage hints.
> sqlite> select path,hash from validpaths;
> /gnu/store/98xcn26354r70nyamkgywqzjxvw3qikx-guile-2.0.9.tar.xz|sha256:a475e4bad3d39a94f01c590f239e80dbd84688e480ca74de3e335f6f36a0d975
> /gnu/store/hyh7kwkqlxc0x9s8cs5mjnih5v524486-make-impure-dirs.patch|sha256:d697a02be5fea425ac93eb650b1359e3e8053d84f70677c8c0a80291ed03585e
> /gnu/store/hv15hq91vm3ajv23lkq0kgd56d4kmd08-findutils-absolute-paths.patch|sha256:c4fc83e01a7f448b598905bcf6ca39b5ba0f1f0f131145b379f0de9c2fbe109b
> […]
> --8<---------------cut here---------------end--------------->8---
> 
> (Of course you have to trust the database to contain the right hashes in
> the first place.)
> 
> Ludo’.

That is part of the reason I also suggest an external utility, and ideally one
that is simple enough that people could (re)implement it in their language of
choice (so that what and where the script is is generally
unknown/unknowable/really hard to find, as well as much more difficult to
compromise via simple methods such as patching).

Heck, since your normal user can read the store, one should be able to
reasonably compare the currently stored database to something the user has
generated via

# Please note that I'm not 100% sure this is correct. I don't think you'd want
# to include .link files, but I'm unable to find a quick way in the minute or
# two I wrote this to avoid them. Plus I'd expect some things to be checksumed
# that don't really need it.
$ find /gnu/store/ -type f -print0 | xargs -0 sha256sum

or something similar, given that sha256sum isn't compromised. Once the two are
known to be in sync (ideally with some form of external verification, and by
external I mean booting and mounting the system under a Known Good liveUSB or
similar and checking the database against the system's sha256sum as well as the
liveUSB's Known Good version), then comparing to another person's checksum dump
(ideally someone you know properly checks their system via the aforementioned or
better method) to try and catch potential unwanted modification.

The obvious problem would be removing entries for programs known to not have a
deterministic build (which makes all of this entirely moot for said program),
and hope they aren't compromised and aren't Very Important to the system.