5 ms·

Yes, just write it into a database or something, and rewrite the entire ecosystem to play nice with this new MTA that doesn't compose with existing tools. Wave

by clarry 7y ago

Yes, just write it into a database or something, and rewrite the entire ecosystem to play nice with this new MTA that doesn't compose with existing tools. Wave hands until the problem solves itself somehow?

jcranmer 7y ago
I mean, you'd have to design some sort of Mail Access Protocol to be able to get to this database, and then get everyone to be able to use that protocol. Surely that's impossible.
- 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 ago
    You 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 ago
    I 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 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 ago
        It 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 ago
    Things 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.
- e12e 7y ago
  I'm not sure if you're joking, but there are a couple of such protocols - IMAP being the most prominent. As for opensmtpd, it should probably only reject, drop or hand off mail via LMTP. Then another daemon should deal with storage and provide access to mail. You might look at dbmail.org if you want mail storage in PostgreSQL with IMAP support, for example. Dovecot can handle incoming mail via LMTP, but needs roit to write to mailboxes, unfortunately. I suppose you could give each user a suid binary to handle incommming email... Not sure if that'd be a great idea, though. Ed: ironically, a change along these lines resulted in this bug. Maybe it would be better if opensmtpd only spoke LMTP, and never did any launching of a shell. Conceivably the LMTP daemon might have a similar bug, though..
  - anonsivalley652 7y ago
    I wonder if instead of running a single mail delivery agent as root that can touch everything everywhere, a separate child process should run as that user and chroot/drop privs to where it can only write to mbox files and log if it can't. Or at least confine it to mbox files via SELinux, which still seems too open. Processes running as root for fs permissions reasons only is usually an ops smell that something wasn't architected or configured correctly.
    - akira2501 7y ago
      I believe you're basically describing the architecture of qmail.
      - anonsivalley652 7y ago
        Not even close. Qmail is quite different in that it uses maildirs instead of mbox and does a bunch of things differently including proprietary formats. And it's under-maintained and not widely used. I was only talking about the delivery of mail, not rearchitecting the world.
    - edoceo 7y ago
      For mail, they also need low ports, which typically requires root.
anonsivalley652 7y ago
Hey now, OpenSMTPD shouldn't be compared to systemd.

by clarry 7y ago

jcranmer 7y ago

I mean, you'd have to design some sort of Mail Access Protocol to be able to get to this database, and then get everyone to be able to use that protocol. Surely that's impossible.

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 ago
  You 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 ago
  I 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 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 ago
      It 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 ago
  Things 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.
e12e 7y ago
I'm not sure if you're joking, but there are a couple of such protocols - IMAP being the most prominent. As for opensmtpd, it should probably only reject, drop or hand off mail via LMTP. Then another daemon should deal with storage and provide access to mail. You might look at dbmail.org if you want mail storage in PostgreSQL with IMAP support, for example. Dovecot can handle incoming mail via LMTP, but needs roit to write to mailboxes, unfortunately. I suppose you could give each user a suid binary to handle incommming email... Not sure if that'd be a great idea, though. Ed: ironically, a change along these lines resulted in this bug. Maybe it would be better if opensmtpd only spoke LMTP, and never did any launching of a shell. Conceivably the LMTP daemon might have a similar bug, though..
- anonsivalley652 7y ago
  I wonder if instead of running a single mail delivery agent as root that can touch everything everywhere, a separate child process should run as that user and chroot/drop privs to where it can only write to mbox files and log if it can't. Or at least confine it to mbox files via SELinux, which still seems too open. Processes running as root for fs permissions reasons only is usually an ops smell that something wasn't architected or configured correctly.
  - akira2501 7y ago
    I believe you're basically describing the architecture of qmail.
    - anonsivalley652 7y ago
      Not even close. Qmail is quite different in that it uses maildirs instead of mbox and does a bunch of things differently including proprietary formats. And it's under-maintained and not widely used. I was only talking about the delivery of mail, not rearchitecting the world.
  - edoceo 7y ago
    For mail, they also need low ports, which typically requires root.

anonsivalley652 7y ago

Hey now, OpenSMTPD shouldn't be compared to systemd.