Hi,
On Fri, Dec 29, 2017 at 09:55:15PM +0100, Markus Wanner wrote:
> On 12/29/2017 09:17 PM, Josip Rodin wrote:
> > On Sun, Dec 24, 2017 at 09:17:28AM +0900, Osamu Aoki wrote:
> >> Another option is create another wrapper code such as maildrop-suid-root
> >> which is a SUID on root program and let it calls maildrop in upstream.
> >> And make courier call this new code. This needs upstream cooperation.
I think the upstream is cooperating. It's mostly Debian internal issue,
I think.
> I brought up the issue on their mailing list, but upstream wasn't
> exactly cooperative. They think of maildrop being available in two
> different flavours: standalone and courier-mta bundle.
Yes. To be precise, as I understand, it was available in two different
flavours for jessie:
* maildrop (standalone): SGID mail
* courier-maildrop (previously available with courier-mta): SUID root
But for stretch, courier (0.75.0-15) maintainer changed this:
...
* Kill duplicate courier-maildrop package and just depend on standard
maildrop package
(Closes: #289091, #193650, #567462, #684230)
-- Ondřej Surý <ond...@debian.org> Wed, 16 Mar 2016 16:45:48 +0100
I suspect this may have been a bad move and thus its broken in
stretch/stable now if I believe bug reports. (I don't use courier. If
it is not a problem at all, please close all related bugs.)
They have the same source tree for maildrop but are meant to be build
with differently to accommodate different permission in mind by the
upstream. Upstream understands Debian maildrop package use case and
kindly accomodeted it by changing build behavior with HAVE_COURIER
variable. libs/maildrop/confifure.ac has:
| if test -d $srcdir/../../courier
| then
| #
| # This version of maildrop is integrated into Courier mail server
|
| AC_DEFINE_UNQUOTED(HAVE_COURIER,1,
| [ Whether this version of maildrop is part of Courier ])
| fi
So the binary build in the standalone source tree and in the courier source
tree are different.
Unlike other MTA which uses "root:mail", courier uses different user
"root:courier". It's postinst hasd the following:
| add_override root courier 4755 /usr/sbin/rmail
| add_override courier courier 2755 /usr/bin/mailq
| add_override courier courier 6755 /usr/bin/cancelmsg
| add_override root courier 2755 /usr/sbin/sendmail
| add_override courier courier 4755 /usr/lib/courier/courier/submitmk
| ...
I am not familiar with the security model of courier-mta, but for some
reason they are using this set up. If you read maildrop source looking
for HAVE_COURIER, it looks like maildrop source build with this variable
set to 1 to build courier-maildrop has special case handling. Upstream
make it clear via its comment. The main difference is found in
libs/maildrop/main.C:
| #if HAVE_COURIER
| "Courier-specific maildrop build. This version of maildrop should
only be used"
| #if CRLF_TERM
| "\r\n"
| #else
| "\n"
| #endif
| "with Courier, and not any other mail server."
| #if CRLF_TERM
| "\r\n"
| #else
| "\n"
| #endif
| #endif
...
| uid_t my_u=getuid();
|
| if (setuid(my_u) < 0) // Drop any setuid privileges.
| {
| perror("setuid");
| exit(1);
| }
|
| if (!found)
| {
| #if HAVE_COURIER
| if (!deliverymode)
| #endif
| {
| my_pw=getpwuid(my_u);
| if (!my_pw)
| {
| errexit=EX_TEMPFAIL;
| throw "Cannot determine my username.";
| }
|
| maildrop.init_home=my_pw->pw_dir;
| maildrop.init_logname=my_pw->pw_name;
| maildrop.init_shell=
| my_pw->pw_shell && *my_pw->pw_shell
| ? my_pw->pw_shell:"/bin/sh";
| maildrop.init_default=
| GetDefaultMailbox(my_pw->pw_name);
| }
| }
(delivery.C difference is actually none after the Debian patch which I
should upstream.)
> >> I don't want to maintain any SUID root program. Too much
> >> responsibility. If you are willing to take over this package
> >> maintenance, I can help 2 binary package script.
> >
> > It doesn't make sense to add a new setuid root binary in the maildrop
> > package. Whatever problem there is to solve, more setuid root by default
> > is simply not a legitimate solution without a big fat obvious rationale
> > about how it's unavoidable. Let's not jump to any such conclusions
> > beforehand.
Upstream basically agrees with your assessment for our standalone use
case and accommodated it. But in the courier MTA use case, the upstream
apparently had need to keep this program setUID root and added some
extra codes to take advantage (code before the quoted section seems to
be for such purpose) of it and to limit it privilege as quoted in the
above.
> I wonder if SUID is related at all. In my own setup, while using virtual
> domains in combination with maildrop, it wouldn't even need SGID, I
> think. But I'd have to check why it was SUID to begin with. Or if it is
> in the variant upstream installs.
You may be correct for your use case. I can only guess ... some courier
package which uses maildrop in "deliverymode" needs to set its UID and
GID to "courier:courier" to function. (At least the upstream thought
looks so to me.)
Technically building maildrop and courier-maildrop flavours of binary
packages from the same maildrop tarball is possible by fooling
configure.ac. I can help this technical part but for all the trouble of
securing setUID root is not my thing.
If the courier maintainer deems that he needs such special maildrop
custom build for courier mail security model while avoid having the 2
identical source base maintained and build independently in Debian, he
needs to step up to join and lead the maintenance of this maildrop
actively while taking full responsibility for the SUID root version.
The simpler thing to do than building 2 packages from the same maildrop
tarball is to revert the change in the courier package and not touching
the maildrop package. Then keep talking to share patches.
Regards,
Osamu
