Hi, I thought about this .... I now agree with you on the runtime detection approach you are talking.
On Tue, Jan 02, 2018 at 10:01:06AM +0100, Markus Wanner wrote: > On 01/02/2018 01:15 AM, Josip Rodin wrote: > > All of those changes related to HAVE_COURIER sound like something that > > should be possible to figure out on runtime. Relying on the existence of other files may not be the best idea. I now think of a simpler runtime detection method. If "maildrop" binary has its file permission with "suid root", HAVE_COURIER equivalent dynamic variable to be true. If a malicious user have right to set such capability to enable this, you system is already compromised. > That's exactly what I thought as well and proposed, but upstream > rejected as an additional security risk. Maybe it's worth trying again with exact patch. > > I still don't see a rationale for that. The existence of those measly few > > lines about the HAVE_COURIER define, that we then have to interpret and > > reverse-engineer and whatnot - simply don't constitute a valid rationale > > for adding back a binary with suid root by default. > > Exactly my line of thought as well. If courier platform doesn't require it for sure, then please don't set suid root. If you need suid root for courier, add a courier-maildrop package which depends on maildrop and have postinst/rm script to set permission via dpkg-statoverride mechanism on the patched binary as discussed above. Or add README.Debian of maildrop to instruct this dpkg-statoverride trick without adding the courier-maildrop package. > > I think we need to ask Sam to document this properly, and only then proceed > > with any further considerations. > > That's fine with me. Yes. Anyway, let's forward debian/patches/0003-permanent-err.patch first. That will reduce one occurrence of HAVE_COURIER. This basically changes non-courier maildrop to behave like updated courier one. I think this moves key discussion of HAVE_COURIER to a single meaningful point. Regards, Osamu
