On Sun, 15 May 2011 18:18:39 -0300, Henrique de Moraes Holschuh <[email protected]> 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". -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
