Re: Bug#626641: cryptsetup: bug #587220 re-introduced
On Sun, 15 May 2011 18:18:39 -0300, Henrique de Moraes Holschuh
<hmh@debian.org> wrote:
> OTOH, all it takes to handle a dm-crypt device you forgot open is the
> direct use of dmsetup, or simply reinstalling cryptsetup. Or a system
> reboot/reset. Or a system power off.
A system power off or dropping the mapping directly via dmsetup (which an
end-user does not necessarily know[0]) may not be enough:
I'm not sure whether milan has already implemented anything with respect
to this, but eventually the dm-crypt keys in memory (and perhaps the whole
memory itself) should be securely wiped.
Not sure whether he'll put that in the DM level, however, so you may be
right and dmsetup might be enough.
But than you depend on dmsetup and you just moved the problem.
>> 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.
> ...
Yes?
It's like gnupg, where you also want to have clear exit codes under any
circumstances, and not sometimes exit 0 though a signature verified wrong.
[2]
> Well, initscripts *are* mandated to FAIL if they cannot shutdown the
> service. So yes, if there are cryptsetup disks open and you tell the
> initscript to stop the service, and it cannot close the disks, it IS to
> return failure.
Have you actually had a look at the code? I doubt.
With the most recent upload (and this is the very reason why I've reopened
the bug), you can have the situation (package removed but not pruged) where
you say:
/etc/init.d/cryptdisks stop
and it gives you just $? = 0, as /lib/cryptsetup/cryptdisks.functions is
gone.
> OTOH, if there are *no* cryptsetup disks open to close in the first
> place, it is to return success.
THAT is fully ok of course,... and I've never said anything else...
> It is not an 'essential package' by any means. However, we have a very
> strict technical definition of what an 'essential package' is, and that
> definition is directly related to the packaging system and a few other
> system details.
>
> So you likely misunderstood me there. It has nothing to do with how
> essential cryptsetup is to your usage of a particular Debian system.
Yes I know that it's _not_ essential in the sense of the Debian Policy and
the "Essential: yes" control field, but, and this is what I'm trying to
explain the whole time, it is essential with respect to it's usage.
This means:
If you're someone who (seriously) wants to do disk encryption, than
cryptsetup (and that it perfectly works[2] in any circumstance is the most
essential thing on earth for you ;-)
And therefore I'd say, that there are some packages in debian (e.g.
cryptsetup, gnupg, openssl) which really need very special handling.
And this is also the reason why I've had quite some discussions with Jonas
before. While some of them were just rejected additions of features or
making the whole thing work in more setups (e.g. when /usr is network
mounted, etc. etc.) some were also about these small and inconsiderable
pieces, some may seem to be very nitpicking, but all of them are utterly
important when one wants real security.
This is not only "small things" like "secure" exit codes,.... but can be
things like securing the shell execution environment in all scripts (was
also reject, though it's a two liner), or adding documentation why
something is done, or (sometimes even more important) why something is
deliberately not done.
Again, I hope that Jonas doens't feel offended or so,... I just miss the
strong sense of care that is required for security in many places.
Cheers,
Chris.
[0] And we shouldn't exclude "end users" without deeper knowledge from
having a "secure as possible system" if they can get if "for free".
Reply to: