On Tue, 2011-05-17 at 00:24 +0200, Jonas Meurer wrote: > I think that one is the trouble spot. Christoph doesn't agree with the > way, Debian manages initscripts. They're handled as conffiles by dpkg, > and for that reason aren't removed at 'apt-get remove', only if the > package is purged. Yes I don't ;-) and also their exit codes in some cases. But that's a different construction site ... > For that reason, the situation that initscripts are > still around but the daemon/application they start/stop/whatever isn't, > is quite common. And it would be absurd if initscripts would exit wit $? > != 0 in that case. Here the problem is simply: - dm-crypt devices might be open - cryptsetup might be removed but not purged - a user does /etc/init.d/cryptdisks stop (perhaps even from a script) and believes in good faith that if $?=0 (and especially as even no warnings appeared anyway) that his data is now secured - but it is not. > In case that this needs to be discussed, we should discuss the reasons > why initscripts are treated as conffiles in the first place, instead of > discussion symptoms of this decision. Phew I guess there are already some requests against the policy open,.. both for this config-file-weirdness and for adhering to the (not so unreasonable) LSB exit codes. I've followed this some time and most arguments against these changes seemed (at least to me) to be rooted in avoiding work (e.g. as it would be then necessary to improve the init-scripts and make them "fully" configurable via their respective /etc/default/foo). Anyway,.. there probably won't be any progress soon. So why not just fix this in cryptsetup now, as it's easily possible and can avoid potential security breaches. Again, cryptsetup is special here, not only because of its security-nature, but also as it "leaves" behind running stuff after removal (the dm-crypt devices). "Normal" daemons like postgresql/apache/etc. don't have this problem, as they're typically stopped on removal. > I fully agree with Henrique here. My opinion is as simple as: If people > want do do something called serious, then they _really_ should know what > they're talking about. And if these people do remove a package from > their system, they should _not_ assume that it's functionality is still > provided. Personally I don't share this view,... it should be possible for a end user, if he already trusts Debian (which is obviously does), that he can be given system as secure as possible, without knowing all the technical details behind. Because if this would be necessary, all users would have to read at least the complete cryptsetup source-code, crypto kernel modules (and in principle just everyting). > Did I get you right that you suggest to start/stop/restart the > cryptdisks initscript in the debian maintainer scripts? That would be a bad idea,.. and it would most likely not even work, as those devices are in use. > Is it appropriate to warn admins about unlocked devices when the > cryptsetup package is removed/purged? I still don't see the point, but > would be ok with adding a warning to prerm if people mind about it. While this is not a perfect solution,... it would allow us to conform to Debian's strange handling of init-scripts while still doing everything to at least inform the user about any possible security problems he may encounter. That's why I've suggested it before :) Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature