[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#626641: cryptsetup: bug #587220 re-introduced


I really don't wanna step on anyone's toes, especially not Jonas' (as I'm in many cases quite satisfied and happy with his work for cryptsetup), but sometimes I really wonder why this is packaged for Debian at all, as it seems that it's merely intended to be a toy, and not to be used for serious[0] cryptographic security.

Why do I say "toy",... well it seems as cryptsetup is handled like just any normal program, or like lvm or mdadm. Of course, from a technical point of view, this is true, it just sets up some DM mappings, but the intention behind it (well at least if used seriously) is strong security.

Of course we do not warn the user if he e.g. removes postgresql, that he won't be able to use his DB any longer and we also don't warn him that he'll get into troubles when removing lvm2.

But the difference is, that for those it would just cause breakage, but not the (possible) complete destruction of a possibly long-term and wide ranging security model.

Why?! Simply be cause one might be in desperate troubles, closing his devices with sensitive data (consider the police already knock your door).

Of course you can always argue "an expert user should know that", but why - if absolutely unnecessary - should we let such things open, if we can prevent the users from shooting in their foot.

You also wouldn't remove any secmem usage from gpg, just because an expert user should know that he has to encrypt his swap partition.

And honestly, I don't see much of a difference with the warnings when removing the running kernel.... or are there any bigger problems that modules that should be newly loaded would not be found?!

Ideally, in a package like cryptsetup, operations should either fully succeed or fully fail, so that a user at least knows that he's in trouble. For some of such bugs (e.g. exit code problems with cryptdisks_start/stop) I was already able to convince Jonas after sometimes long discussion to fix this, for others (init-scripts) he's more or less bound by the policy which is IMO for historical reasons wrong with respect to init-scripts (exit codes, and their handling as config files[1]).

E.g. if I say /etc/init.d/cryptdisks stop, I expect that any cryptdisks are stopped (well at least ne not "early" ones) and if this didn't work for some _valid_[3] reason, a warning should be given and in any circumstances exit code should be != 0.

What makes me really sad with respect to all this is, that Debian obviously doesn't understand that things like cryptsetup must be handled very sensitive and much more special than most other programs. This is also, why I unfortunately must advise against using Debian's cryptsetup in many cases on the dm-crypt mailinglist; at least if "perfect"[0] security is desired.

And it's especially frustrating as for many things (some keyscripts, etc.) alternatives or easy fixes would be available.

Words like "Messing with the running kernel, messing with 'essential' packages..." (and I guess you mean implicitly that cryptsetup is not essential) demonstrate quite well the wrong understanding of cryptsetup... for someone who really wants to do serious security, the functionality of most essential packages is completely uninteresting (except as far as needed by cryptsetup)... because their failure would just mean e.g. an unbootable (but still secure) system.

Apart from that,... I honestly don't think that it's necessary to modify well written initscripts (and it shouldn't be) in 95% of all cases. Most configuration of the initscript itself or daemon parameters can be don in /etc/defaults/<foo>... And we already have lots of nicely written initscripts (e.g. postgresql/zope) that show that it's even possible to run multiple servers with one single init script.
If you need another good reason why something's wrong there, see [2].


[0] Please don't use the argument that there's always a weaker element in the chain, like torturing you to death.... if we argue like that we could more or less completely drop many crypto/security packages.

[1] I mean the whole idea of configuring init-scripts via /etc/defaults/<foo> already shows that something's going wrong there ... having a configuration file for a configuration file?!

[2] Which is not "the user broke the scripts".... but he did something allowed like "remove but not purge".

Reply to: