3 ms·
I host my own email. On assuming minimal threshold of competence.. you'd probably want to assume that nobody today plasters strings (while trying to escape the
by clarry 7y ago
I host my own email.
On assuming minimal threshold of competence.. you'd probably want to assume that nobody today plasters strings (while trying to escape the untrusted bits) to make SQL queries; many a database have been compromised this way. Here we are, looking at OpenSMTPD which did essentially the same: pass untrusted string to shell. Whoops. For anyone whose production email system were subject to such an issue, it's bad, really bad, whether it's an SQL query going against unprivileged database with all your data in it, or string going to root shell.
I'm not terribly concerned about a piece of a daemon running as root. It's not the entire daemon, just a small privileged helper performing a tiny set of functions. I'd like to see it go, and I think it could go if we compromise on some features, change the way MDAs are invoked, or use a different permission model. The last one would probably be a relatively small change and allow existing tools to work (perhaps with small changes).
I don't want to introduce a database and a daemon to store messages into it and another to let me read them. That's just adding more code, I want less code. I want a better security model, not shuffling responsibility away into a different daemon that needs to be maintained and audited and protected from a subtle big whoops.
- juped 7y agoIt passed a trusted string that it was wrong to trust to the shell. Big difference, even if some of the ultimate mitigations are the same.