4 ms·
So now instead of privileged daemon forking MDAs to deliver everyone their mail, we have a database holding everyone's mail and everyone's connecting to that da
by clarry 7y ago
So now instead of privileged daemon forking MDAs to deliver everyone their mail, we have a database holding everyone's mail and everyone's connecting to that database, presumably through some daemon that can now access everyone's mail... maybe it doesn't run as root but I'm not convinced this improves the situation more than it shuffles the point of failure around (and arguably introduces more of such points).
- viraptor 7y agoYou already need a daemon which can access everyone's mail. Unless you're the only mail user on a server, whatever piece of the system logs you in, it dispatches the request to a given mailbox - it has to have global access by design. (even if indirectly by spawning another process with the right privileges) Disconnecting the concept of an email user from a system user definitely improves the situation and is unlikely to introduce new failure points. That's how the biggest email providers work - you don't expect gmail to create a new uid for you when you create an account, right?
- jcranmer 7y agoI don't know what email service you use, but it's probably storing your email in a distributed database. An ancillary effect of using an actual database is that they generally play nicer with backups and actually making sure that you don't lose any data if the power goes out (doing this yourself is a recipe for disaster). Using a database doesn't require a privileged daemon, and the worst-case scenario (assuming a minimal threshold of competence) is that any attacker can only screw up the database in some way. With a privileged daemon, screwing up generally means that the attacker can potentially gain full control of your hardware, with all the nastiness that entails. Including, at a minimum, read your email or surreptitiously delete them.
- clarry 7y agoI 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.
- deleted 7y ago[deleted]
- Avamander 7y agoThings like `maddy` seem much less error-prone and secure than the, frankly, house of cards of an e-mail stack most boxes run at this moment.