Re: Bug#626641: cryptsetup: bug #587220 re-introduced
Hey...
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].
Cheers,
Chris.
[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: