Wietse Venema wrote:
Christian Franke:
Hi,
just for info: I ported postfix 2.11.3 to Cygwin.
The patch:
http://chrfranke.no-ip.org/cygwin/postfix-2.11.3-1.src.patch
Shouldn't break builds on other platforms. This was tested on Debian.
Generally, this patch skips crucial security/safety features that
are difficult to enforce through a POSIX-on-Windows API. I see no
enforcement of uid/gid separation (permission checks are made in
the program itself instead of in the OS kernel, uid/gid numbers are
passed in an environment variable instead of being protected by the
OS kernel), weak or no enforcement of directory/file/socket
permissions,
This is not the case.
Cygwin does a good job mapping POSIX users/groups/permissions to Windows
users/groups/ACLs. Its setuid() emulation actually performs user context
switching.
https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview
Like Cygwin's crond and sshd, the postfix master runs under a privileged
Windows user account (default "cyg_server"). Unlike normal
administrators, this user is able to perform user context switching
without password. This user has some Cygwin uid (and gid) which is
unfortunately nonzero. All the cygwin_get/set*id() emulation functions
in sys_compat.c do is a mapping between 0 and this uid (gid).
The various postfix daemons calling e.g. setuid(var_owner_uid)
*actually* switch to the unprivileged Windows user $mail_owner. The
[C:/cygwin]/var/spool/postfix directory is actually owned by $mail_owner
and the Windows ACLs are set accordingly. The local(8) daemon actually
switches to the user context of the recipient mailbox. All permission
checks are made by Windows.
The environment variable is only used for a special case: If local
delivery is not needed, Cygwin postfix could be run solely under an
unprivileged user. This works because Windows does not restrict IP ports
below 1024 to privileged processes. The cygwin_* functions then fake the
0 <> var_owner_uid switch. The current emulation state is passed via an
environment from master to daemons. I agree that this is a hack, but it
increases security for this use case because even the postfix master
runs as $mail_owner.
and no enforcement of file size limits.
Yes. Unfortunately Cygwin does not implement RLIMIT_FSIZE because
(AFAIK) there is no equivalent in the Win32 API.
And yes, there are other aspects which differ from POSIX systems.
Could I support this weakened version of Postfix? I would not put
my reputation on the line.
Of course I do not expect that this patch will be accepted upstream :-)
To run Postfix on Windows, I suggest using a VM with BSD or Linux,
or doing a proper port. The port would abstract out Postfix
security/safety features and provide different translation layers
for POSIX and Windows environments (instead of emulating a POSIX
subset on Windows)
A first step for a translation layer would be to replace all (uid == 0)
checks by something like (is_privileged_uid(uid)). I actually tried this
but dropped this approach for now because there are so many of such
checks in postfix :-)
Christian
