On 7/30/2013 8:37 PM, Ben Morrow wrote: > At 3PM -0700 on 30/07/13 you (Joseph Tam) wrote: >> Martin Burgraf writes: >> >>> And when it's running as root there is always the danger >>> of privilege escalation. LDA only runs when it's needed and since it >>> uses only user rights it shoudbe more harmless. >> >> I didn't contest the privilege separation aspect, as it a necessary >> design trade-off that one daemon doing things for all user will need >> overriding access. However, if this is a concern, you can virtualize >> all your users. LMTP can theoretically be subverted, but at least won't >> be as root. (I'm assuming LMTP stays as root, and not spawning off user >> processes to do the real work.) > > It doesn't stay as root; Dovecot's LMTP switches down to the user's uid > to perform delivery, including sieve scripts. The security concerns are > in fact very similar to LDA: for LDA delivery with (say) Postfix, you > have local(8) running as root and switching down to the user to invoke > the LDA, while for LMTP the Postfix lmtp(8) process runs as an > unprivileged Postfix user and the LMTP server runs as root and switches > down. > > AFAICS the LMTP conversation itself happens as root, though, which is a > shame; I might think twice about exposing it directly over the network.
Shouldn't a few iptables/pf rules be able to substantially mitigate this potential problem? I.e. restrict which hosts a given host is allowed to speak LMTP with. -- Stan