On Tue, Aug 18, 2020 at 06:34:27AM -0400, Remco Rijnders wrote: > On Mon, Aug 17, 2020 at 10:37:57PM -0500, Derek wrote in > <20200818033757.gd28...@bladeshadow.org>: > > It's worth pointing out one additional point that I haven't: The > > data in an attachment might be considered sensitive by the person > > sending you the attachment, whereas to YOU it doesn't matter in the > > slightest. By relaxing your umask, you're reducing the security of > > all of your senders' data, BY DEFAULT, without their knowledge or > > consent. > > That seems a bit far fetched to me. If you don't want your precious > attachment to make it out to the public, don't send it. Once you hit > send, it is out of your hands, a umask in mutt is not going to make > a difference there.
Here, you are displaying your ignorance of threat models. The user may, in practical terms, have no choice, because sending you their (or your) sensitive data may be a requirement for some formal or informal transaction that they (or you) are about to perform. It could be something that they are doing on your behalf, or vice versa. Or it could be info that one of you is providing the other on behalf of a third party, on whose behalf you are acting as agent, perhaps in the legal sense of the word, or perhaps informally. E-mail is a bad choice for such a transfer and much better options do exist, but it is still somewhat commonly used because it is ubiquitous and convenient. There's also a huge difference between intentionally, maliciously sharing someone's data, and doing so inadvertently, unintentionally, simply because you've made a poor choice about how to configure your tools. You probably trust your mom not to give out your banking info to random strangers. Unless your mom happens to specialize in secure software development or application security administration, I imagine you DON'T trust her to understand how to configure her mail client securely. Although, it's worth pointing out that many victims (of all sorts) are attacked by their own family members, whom they trusted. Even in those cases, it should require action on your part--not default action on Mutt's part--that gets you owned. It should never be possible to BLAME MUTT for this. > > > The difference between us is basically that I prefer that the user > > > have the *possibility* to do it in the "wrong" way after being > > > warned about consequences. Of course sane/secure defaults are a > > > must. > > > > Have you not been paying attention to the heat that Facebook and other > > sites have been taking for their lack of care in protecting users' > > sensitive data? > > That is not a good analogy. Of course it is. In both cases the user is entrusting some level of their data security to the policies and practices of a third party (either Facebook, or mutt-dev), largely because they are unqualified and incapable of doing so for themselves. Often the user realizes this... in many cases the user does not realize this. It is the responsibility of those trained and experienced in security to make sure that those who aren't don't have to, because history shows they generally will not take the time to try to learn, and even when they do, they will most often fail to understand what they have learned, or the gravity of it in relation to their specific circumstances. It's exactly the same for Facebook as it is for mutt-dev. > Sacha was not proposing changing anything like that but just > proposing a patch that would help them and perhaps make others life > easier too; No defaults would be changed Again that's just wrong. A configured default is still a default. If you aren't given the opportunity to decide how securely to save the file, then the exhibited behavior is the default. Anyone who sets a relaxed umask has created for themselves a default of insecure saved attachments. You can't know that there's sensitive data in it until you see it, which requires saving it to disk. The instant it is on disk and readable by anyone but you, if there is a knowledgeable attacker on your system who is targeting you it is already too late for you to do anything about it. > and I can't see how this would catch anyone unaware. Again, that's the problem, as it so often is with security: YOU can't see it. But if an attacker is aware of it, they sure as hell will exploit it. You can be unaware because you don't have the facts. You can also be unaware because you don't understand the facts that you have, or lack adequate imagination as to how those facts can go wrong for you. Anyone who uses a relaxed umask has made a bad decision, period. The feature should therefore not exist, so that users do not have the opportunity to make what can ONLY be a bad decision. The fact that YOU, or any particular developer or mutt user can't see that is not a good enough reason to compromise Mutt's security, most especially when the benefit in convenience of doing so is actually so small, as in this case. > The subject has been dropped by Sacha, why can't you just let it > rest at that? I would love to, but I can't, because several people who have commit access to Mutt, including (with the official announcement of you joining the mutt developer team) you in this very message, have continued to argue the issue naively. As someone who cares about Mutt and cares about the security of it an its users, it is my duty to do everything in my power to make you understand this issue. Same goes for Vincent. Were people who have commit access not arguing that this feature is harmless (or similar) I would have stopped posting about it two weeks ago. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.
signature.asc
Description: PGP signature
