From mboxrd@z Thu Jan 1 00:00:00 1970 From: dian_cecht@zoho.com Subject: Re: Thoughts on GuixSD and IDS like AIDE and Tripwire Date: Mon, 2 Jan 2017 07:24:26 -0800 Message-ID: <20170102152426.GA29868@khaalida> References: <20161231132814.GA25102@khaalida> <20170101065609.GA4651@mail.thebird.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:37054) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cO4TS-0001yY-W2 for guix-devel@gnu.org; Mon, 02 Jan 2017 10:24:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cO4TP-0001sZ-JE for guix-devel@gnu.org; Mon, 02 Jan 2017 10:24:34 -0500 Received: from sender-pp-092.zoho.com ([135.84.80.237]:25372) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cO4TP-0001rl-Ch for guix-devel@gnu.org; Mon, 02 Jan 2017 10:24:31 -0500 Received: from localhost (khaalida [local]) by khaalida (OpenSMTPD) with ESMTPA id e9a8f1d3 for ; Mon, 2 Jan 2017 15:24:26 +0000 (UTC) Content-Disposition: inline In-Reply-To: <20170101065609.GA4651@mail.thebird.nl> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: guix-devel@gnu.org 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.