4 ms·

… and everything old is new again. DJB’s qmail, written in 1995, was made of 5 distinct processes, owned by different users, with no trust among them. Coincide

… and everything old is new again. DJB’s qmail, written in 1995, was made of 5 distinct processes, owned by different users, with no trust among them. Coincidentally, it was the MTA with the best security record for more than a decade (and also the most efficient one). It would have likely had a similar record even if it was only a monolithic process - because DJB - but it was built as 5 processes so even if one falls, the others do not.

patchtopic 3y ago
it was also essentially unusable without a crapload of third party patches that DJB would not include into the master release, but yes it was quite secure :-)
- Anarch157a 3y ago
  And it was highly vulnerable to denial of service attacks. It didn't check if the mailbox was valid during the envelope phase, so it would queue basicaly everything, then check the mailbox and send a bounce if necessary. Sending thousands of messages to random boxes (dictionary spam attack) would queue thousands of bounce messages that would be rejected by the (faked) sender domain, bringing the Qmail server to it's knees. As me how I know this... Thing is, in most companies, is cheaper and more efficient to deal with a sporadic vulnerability than having your e-mail system DOSed every other week. This is the kind of compromises that normal people and companies have to do all the time, but radicals and cryptopunks like DJB can't seem to understand. Sure, he's a brilliant mathematician and cryptographer, but his grasp of reality outside academia seems very flimsy, IMO.
  - beagle3 3y ago
    My qmail setup in 2000, on a humble beige box, was occasionally under a “thousands of bad addresses” attack, but I only found out about it a few days later while reviewing the logs. There surely was a threshold where it would be down on its knees - but “thousands” and even “tens of thousands” wasn’t it. The exchange server it replaced, though, would crash and burn very often, for a variety of reasons.
microtonal 3y ago
The problem is most developers and companies simply don't care, or are even hostile to improvements ("this is not the Unix way"). We had SELinux for over two decades. We dan do even more powerful isolation than qmail could at the time, yet nobody outside Red Hat and Google (Android/ChromeOS) seems to be interested. Virtually all Linux distributions largely rely on a security model of the 70ies and a packaging model of the 90ies. This is compounded by one of the major distributions providing only 'community-supported security updates' for their largest package set (which most users don't seem to know), which unfortunately means that a lot of CVEs are not fixed. A weak security model plus outdated packages makes our infrastructure very vulnerable to nation state-funded attacks. The problem is much bigger than this compromise of xz. Hostile states probably have tens if not hundreds of backdoors and vulnerabilities that they can use in special cases (war, etc.). It's endemic not just to open source. macOS has supported app sandboxing since Snow Leopard (2009), yet virtually no application outside the App Store (where sandboxing is mandatory) sandboxes itself. App sandboxing could stop both backdoors from supply chain compromises and vulnerabilities in applications in their tracks. Yet, developers put their users at risk and we as users cheer when a developer moves their application out of the App Store. It's time for, not only better funding, but significantly better security than the 70ies/80ies Unix/Windows models.
- nottorp 3y ago
  > no application outside the App Store (where sandboxing is mandatory) sandboxes itself. Usually applications distributed outside the app store would simply not work (or be limited to close to useless) if sandboxed. My pet example these days, DaisyDisk, cannot show what takes 10-30% of my space in the app store version. And can't delete protected files in Applications etc. Which would be nice if it were a malicious free to play game, but it's an application that graphically reports what's taking space on your computer and optionally deletes stuff that you've chosen. So it simply can't work well inside the sandbox.
  - microtonal 3y ago
    Usually applications distributed outside the app store would simply not work (or be limited to close to useless) if sandboxed. I disagree. Sure, there are some applications that need to be distributed outside the App Store because they need additional privileges (like DaisyDisk), but there are many applications that are distributed outside the app store that could be sandboxed. Just to give some examples, why do Discord, Signal, Obsidian, Dash, or 1Password have unsandboxed processes? (1Password was in the App Store and sandboxed before it became an Electron app.)

patchtopic 3y ago

it was also essentially unusable without a crapload of third party patches that DJB would not include into the master release, but yes it was quite secure :-)

Anarch157a 3y ago
And it was highly vulnerable to denial of service attacks. It didn't check if the mailbox was valid during the envelope phase, so it would queue basicaly everything, then check the mailbox and send a bounce if necessary. Sending thousands of messages to random boxes (dictionary spam attack) would queue thousands of bounce messages that would be rejected by the (faked) sender domain, bringing the Qmail server to it's knees. As me how I know this... Thing is, in most companies, is cheaper and more efficient to deal with a sporadic vulnerability than having your e-mail system DOSed every other week. This is the kind of compromises that normal people and companies have to do all the time, but radicals and cryptopunks like DJB can't seem to understand. Sure, he's a brilliant mathematician and cryptographer, but his grasp of reality outside academia seems very flimsy, IMO.
- beagle3 3y ago
  My qmail setup in 2000, on a humble beige box, was occasionally under a “thousands of bad addresses” attack, but I only found out about it a few days later while reviewing the logs. There surely was a threshold where it would be down on its knees - but “thousands” and even “tens of thousands” wasn’t it. The exchange server it replaced, though, would crash and burn very often, for a variety of reasons.

microtonal 3y ago

The problem is most developers and companies simply don't care, or are even hostile to improvements ("this is not the Unix way"). We had SELinux for over two decades. We dan do even more powerful isolation than qmail could at the time, yet nobody outside Red Hat and Google (Android/ChromeOS) seems to be interested. Virtually all Linux distributions largely rely on a security model of the 70ies and a packaging model of the 90ies. This is compounded by one of the major distributions providing only 'community-supported security updates' for their largest package set (which most users don't seem to know), which unfortunately means that a lot of CVEs are not fixed. A weak security model plus outdated packages makes our infrastructure very vulnerable to nation state-funded attacks. The problem is much bigger than this compromise of xz. Hostile states probably have tens if not hundreds of backdoors and vulnerabilities that they can use in special cases (war, etc.). It's endemic not just to open source. macOS has supported app sandboxing since Snow Leopard (2009), yet virtually no application outside the App Store (where sandboxing is mandatory) sandboxes itself. App sandboxing could stop both backdoors from supply chain compromises and vulnerabilities in applications in their tracks. Yet, developers put their users at risk and we as users cheer when a developer moves their application out of the App Store. It's time for, not only better funding, but significantly better security than the 70ies/80ies Unix/Windows models.

nottorp 3y ago
> no application outside the App Store (where sandboxing is mandatory) sandboxes itself. Usually applications distributed outside the app store would simply not work (or be limited to close to useless) if sandboxed. My pet example these days, DaisyDisk, cannot show what takes 10-30% of my space in the app store version. And can't delete protected files in Applications etc. Which would be nice if it were a malicious free to play game, but it's an application that graphically reports what's taking space on your computer and optionally deletes stuff that you've chosen. So it simply can't work well inside the sandbox.
- microtonal 3y ago
  Usually applications distributed outside the app store would simply not work (or be limited to close to useless) if sandboxed. I disagree. Sure, there are some applications that need to be distributed outside the App Store because they need additional privileges (like DaisyDisk), but there are many applications that are distributed outside the app store that could be sandboxed. Just to give some examples, why do Discord, Signal, Obsidian, Dash, or 1Password have unsandboxed processes? (1Password was in the App Store and sandboxed before it became an Electron app.)