Re: debcheckroot v1.0 released
Am 05.04.2014 15:23, schrieb Patrick Schleizer:
Hi Elmar!
This is a most interesting tool!
The opensuse logo on http://www.elstel.org/debcheckroot/ is confusing,
since this is a Debian tool. This might scare of interested people.
Oh, what an embarrassing mishap!
Many Thanks for your evidence , Patrick.
As Debian package headers do not use to be signed
I think you are mistaken here or maybe I misunderstand. When you have a
Debian medium you trust (such as a Live DVD from a trusted source), we
can regard keys in /etc/apt/trusted.gpg.d/ and /etc/apt/trusted.gpg as
trusted.
For example http://ftp.us.debian.org/debian/dists/jessie/InRelease and
http://ftp.us.debian.org/debian/dists/jessie/Release.gpg are gpg signed
by the Debian archive key.
Ah, many thanks for that advice. I had just looked at the Release file
which was and still is not signed (am I right?! - have just checked this
file). However the InRelease file is signed and should contain all the
relevant information: a signature for every Packages.gz which in turn
does contain checksums for every package.
This approach seemed futile to me. At least for now. There are too many
files, that are automatically generated created by postinst scripts. For
example /usr/lib/pymodules/python2.7/**/__init__.pyc gets automatically
generated. Even worse, the file is non-deterministic.
Well, of course debcheckroot is not a 'silver bullet' nor an ultimate
remedy.
However I have already used it to spot rootkits on some core binaries
and the glibc which did not hide in *.pyc or other files generated on
the fly.
You may see the files or more correct a superset of the packages that
had been altered that time when you look into the debcheckroot-script
for the $corepkgs variable. It should thus be already worth to use for
cases where you do not have self-created checksum lists; i.e. at least
for the casual user who does not want to afford higher security. As far
as that would only concern *.pyc one could even consider to remove all
these files if you think your system had been clean before the check
anyway so that you obtain a system which is clean with a considerable
high probability. At least the tool does not suffice without inspecting
all files which are listed as 'unchecked' by debcheckroot; so
auto-generated ascii files ought not matter as a little human effort to
inspect these files is presumed.
In future situation may improve:
https://wiki.debian.org/ReproducibleBuilds
Very pleased to hear from it.
It would also help if Debian had an OEM mode. Links to these discussions
can be found here:
http://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20131209/000010.html
-
For Whonix, Verifiable Builds have been implemented, which is similar to
this tool:
http://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20131209/000009.html
Very interesting. I will have a look on it shortly ...
As a maintainer of Whonix and interested in that feature, I am naturally
interested in your tool.
Great! Though maybe not suitable for a high security distro by the time
I believe the average user will for sure benefit.
If you or someone else would be interested to contribute re-licensing
under GPL should not be a problem at all.
I should have some time for the tool after the next week when my Easter
holidays will begin provided that sufficient interest is given.
Why you should not use debsums
Please don't be so harsh on debsums. It's not for backdoor detection,
but great as a simple integrity check.
Yes, perhaps you are right. However most people whom I know have not got
that, yet ('...').
Cheers,
Patrick
Best Regards,
Elmar
Reply to: