Any value to ('whonix' 'os') script file cheksumming / gpg / {insert current terminology}?

Well … clearly there is value - whether there’s enough value is a different story. No doubt this isn’t a Whonix specific issue / other distros probably make some attempts in this area, but I’ve no idea whether the idea is fully fleshed out anywhere in a manner popularly deemed sufficient, with an acceptably low performance impact.

Any value to checksumming / gpg signing things like whonix scripts, checked at runtime, for something unexpectedly sticking its fingers in the code, perhaps nefariously?

(e.g. A background super-whonixchecker kicked in a boot?)

There are two things here.

  • a) A background checking daemon to spot issues causes by anything but sophisticated malware.
  • b) A tool to be booted from an external (virtual) disk (DVD, USB…) that can also spot alterations by sophisticated malware.


It has value. It could spot physical hdd issues and/or file system bugs that lead to bit flit and unexpected behaver. Non-Whonix specific indeed. Should be implemented as an independent package. When done right (running with low priority? :slightly_smiling:), it should be very much doable performance wise.

debsums does something like this. A command line tool to check file integrity against package meta data. It has no background checking daemon.

Whonix’s build script runs a chroot script that uses debsums as a sanity test at the moment btw. (Shows some usage examples.)

Such an approach could hardly detect maliciousness. Or if it could then only ‘trivial’ malware. Any slightly sophisticated malware will hide itself by being a rootkit. It’s the “antivirus” approach, which is flawed, but still has value. ( https://www.whonix.org/wiki/Computer_Security_Education#Malware )


Such a tool unfortunately does not exist.

Integrity check against package repository?


I was thinking more along the lines of at execution first thing checked for is a sanity check against pgp or something. Insert {your favourite beastie} for pgp there - seems to me pgp (over just a checksum) would add validation sum against a known good ‘original’ (source) value.

I was also thinking a user could self-modify a script, then call something to update the checksum. However, as you in essence point out, if a user could, so could malware.

In any case, this is something Whonix could do for itself if it wished. e.g. ‘Standard’ script calls to calc sum then compares against, say, a www.whonix stored value. I could see where that would be more onerous than www.whonix is interested in sustaining. Or, I suppose, a busy box like ‘super-visor’ - enveloping executable that vets the file, then transforms into that executable.

I take your point that this is more a cross-distro issue, and no point reinventing the wheel. When they all solve it, whonix could make use of the solved problem, then, if it wished to.

Seems to me clamav (to your point about virus checkers) had a checksum ability, but it’s been a while since I looked at it that closely. Even then, as you note, that’s a side process, not an inline process.

Never mind there’s no vetting against a public sum store, if one is off the net at the time.

Package management apt already has all of that data. Packages have check sums that are verified using gpg. I see no reason to not reuse that data.

Nor have I suggested anyone do so.

In any case, how is such used to validate a file (e.g. scripts) at execution / load time?

debsums can do that.

I must be missing something, then.

From http://manpages.ubuntu.com/manpages/natty/man1/debsums.1.html I see how a package can be checked.

I don’t see how debsums helps sanity check, say, whonixcheck, at runtime, unless you’re suggesting some sort of line at the top of every bash script and executable along the lines of: {I know I’m part of package Y} {debsum package Y} {exit if fail}.

Which would also presumably fail if a user modified a .d file. And wouldn’t cover a nefarious .d file inserted.

What am I missing?

(Let alone, how does every source file understand the package it will be included in / going back to each source file at every package change - which seems unlikely to happen.)

debsums can check all packages installed on the system. I didn’t have in mind to run debsums at runtime of whonixcheck. What I had in mind was a background that internally uses debsums to check the whole system.

And if resources (time) are to scare, instead of an independent project / daemon, whonixcheck could run that test.

I didn’t have that in mind but I like the idea.

(There is no such thing as a .d file.) But yes, when using debsums with --config, then any changed config file (from /etc [?]) would be pointed out.

Maybe a good time to explain in whonixcheck “avoid editing config files, use .d style instead - https://www.whonix.org/wiki/Whonix_Configuration_Files”.

The complexity of this and the likelihood of false positives tells me this check should not run by default as it would become a major source of FUD.

No, it would not indeed. Anyhow. For detecting nefarious stuff, you need option b) (which I mentioned above) to begin with. And even then, it would still be a manual system administrator task to manually check such files.

To avoid mixing up topics, please state if you are taking about option a) or b).

Lots of stuff.

  • There are a lot files automatically generated. (in /var …)
  • Worse so, these are often not deterministic.
  • Sometimes non-text, therefore hard to audit.
  • Therefore no one is providing signed checksums of these files.
  • [ Debian is working on deterministic packages. But they are not working yet on deterministic installed packages yet. (During installation the package maintainer script can start various auto generation and start creating non-determinacy.) ]

And I am sure you would discover more such issues as such a tool either a) or b) is being developed.

Lots of work.

  • Work on deterministic installed packages.
  • Audit packages to check if no system compromise is possible even if content it /var is compromised.
  • Handle all these specific cases somehow.

This thread started out with / is premised on:

“Any value to checksumming / gpg signing things like whonix scripts, checked at runtime, for something unexpectedly sticking its fingers in the code, perhaps nefariously?”

> (There is no such thing as a .d file.)

Of course there is, but evidently I phrased poorly. Replace with “a file in a .d directory”, such as whonix_firewall.d.

> Maybe a good time to explain in whonixcheck "avoid editing config files, use .d style instead

Will fight a losing battle. Not to say the note is not worthwhile, but until you change all of debian, all package creators, and all self-coders, such will always be present. Thus counter-productive to warn as the message will continuously flag for things landing upon install, let alone be beyond the user’s ability to control or fix to make the warning go away.

In any case, such would still not bring the element of updating {checksum} upon user accepting a revised file as their new normal.

> To avoid mixing up topics, please state if you are taking about option a) or b).

Neither. As originally stated: “Any value to checksumming / gpg signing things like whonix scripts, checked at runtime”

>> What am I missing?
> Lots of stuff.

Evidently not. I don’t see any explanation wherein debsums does runtime checking.

From what you have said, sounds like you’re getting out of debsums similar to tripwire, which should handle all the use cases you describe. See ‘see also’ at https://en.wikipedia.org/wiki/Open_Source_Tripwire for similar package references. There is probably value to something like this to whonix in making users feel safe / secure / nothing unknown has stuck their fingers into their systems, but that is a larger discussion for elsewhere than this thread.

In any case, I don’t see anything in them bringing anything to the original question regarding runtime checking.

The runtime checking for hdd issues, bit flip and non-sophisticated malware could be implemented as a shell and python library that gets run by any script at startup. Internally it could use debsums. The script can generically figure out which package it belongs to. Approach: dpkg -S $0 or so. It would only check that all non-config files shipped by the package are unaltered. Would not do in-memory checking. And if there was a bit flip, then let’s hope it didn’t also flip in the first self checkup function. If that has value, you tell me.

I’ve checked most if not all of these packages out in 2013 and found them impractical. Then created the following thread:

Almost by definition, things are impractical. I doubt that debsums is any less impractical than, say, tripwire. (Not intending to debate that here.) I guess we have to go back to - security is, by definition, hard on time / energy / resources. Never mind vetting the vetters, web of trust, and internet of things, continuously growing the problem.

Nature of the beastie … and does it bring sufficient value to the party, I suppose.

In any case, although I appreciate the idea of vetting against source, that is too narrow a definition. It does not take into account user changes and files beyond original. Installations aren’t static. e.g. A file of contacts, with a changed phone number, could in theory be disastrous for the audience whonix is trying to serve.

I don’t disagree wasteful to reinvent the wheel, let those willing to dive in to the fiddly bits of such do so, and leverage that work - which would apply across all systems everywhere.

Not to say whonix can’t do its own thing for its own development, e.g. scripts, the runtime value of which was the question of the OP.

> The runtime checking for hdd issues, bit flip and non-sophisticated malware could be implemented as a shell and python library that gets run by any script at startup.

Without kernel change or the ‘ick’ of LD shimming (which would itself be suspect, particularly in a chain)?

I wonder to what extent selinux, apparmor, or a bastion host brings to the whonix party. (Integrity of system, vs. anonymity of outgoing network stream.)

In any case, seems the answer to the value of runtime checking is ‘yes’, however the solution to doing so is not present. And it is likely this is a well known issue that others than whonix are cognizant of and likely beating on, and we’ll probably hear about it if it is ever solved satisfactorily.

Doesn’t mean whonix couldn’t ‘sign’ its own stuff if it wanted to, I guess.

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]