Re: [Dovecot] LDA vs. LMTP
Martin Burgraf writes:
I don't know why you would consider a background process inferior to a run-on-demand executable.
Well, the background process is hogging CPU and RAM while it basically does nothing.
"Hogging" CPU and memory is putting it strongly, as it is basically suspended while blocked on waiting for a connection, and if left for a long time in an idle state, might be swapped out to disk and not consuming (real) memory, or consuming real memory that isn't in use otherwise.
As I stated before, the resource usage is small compared with all the other stuff going on, so if you don't have a busy mail server, I don't think you should sweat the difference.
The benefits of LMTP should increase with load, as having LMTP resident will save you the overhead of repeatedly loading/unloading LDA, and I'm sure the CPU and memory usage of servicing that overhead will be non-trivial. If you have oodles of memory, then it's no problem keeping a LMTP resident. If you don't have enough memory and are VM disk thrashing, you'll have other problems and LDA/LMTP is the least of your worries.
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.)
Joseph Tam jtam.home@gmail.com
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.
Ben
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
participants (3)
-
Ben Morrow
-
Joseph Tam
-
Stan Hoeppner