On Fri, Aug 07, 2020 at 12:56:34AM +0200, Vincent Lefevre wrote: > On 2020-08-06 10:50:23 -0500, Derek Martin wrote: > > On Wed, Jul 29, 2020 at 12:55:07PM -0500, Derek Martin wrote: > > > On Tue, Jul 28, 2020 at 08:03:23PM +0200, sacham...@s0c4.net wrote: > > > > The thread, and even older threads referenced there, is from 2007. > > > > Since then, the security field have evolved - now we have SeLinux, > > > > Apparmor and other techniques which are capable to provide even > > > > better security than umask(077) > > > > > > None of those changes affect this issue in any meaningful way. > > > SELinux predates that thread by at least two years (longer, though it > > > was not generally available to the public until ~2005). The arguments > > > made in those threads still stand, and I will not repeat them here. > > > > And FWIW, here's a more precise and detailed description I posted MUCH > > more recently than 2007, which explains why this is a bad idea. > > Everything here remains true, regardless of any evolution you think > > has happened in the security world. > > > > https://www.mail-archive.com/mutt-users@mutt.org/msg49810.html > > Perhaps the OP is on a system where each physical user is in his > own group, but possibly with several user ids: the main id would > typically use mode 0600 for all private files, but the secondary > ids would use mode 0660, i.e. the main id can access the private > files of all ids of the user, but the secondary ids would be able > to access only their private files.
Are you serious, Vincent? I'm pretty sure you well know that this is a horrible idea, clearly contrary to best security practices, that no competent sysadmin managing servers holding anything vaguely sensitive would ever allow on a multi-user system (and we've already established that systems only ever used by one human render the configurable umask moot). This is system security 101 (e.g. SANS GSEC). Users to usernames are 1:1. Just the complexity of managing all those extra usernames increases the likelihood that one or more of them is misconfigured, or that the files they own are improperly protected, allowing inadvertent access to someone's sensitive files. It also greatly increases the likelihood that the user will "lend" one of their "spare" usernames to someone who shouldn't have it, not realizing what it allows them to do (or see). And for all those reasons and others it increases the complexity of auditing, with certainty, who is doing what on the system that might be compromising its security. > On such a system using umask (007) for secondary ids seems logical > and safe. No, it doesn't. Even if someone were to run Mutt on such a horribly mismanaged system, its system security is generally suspect, so it is even more important for Mutt to make sure the files are never saved readable by anyone other than the user who created them. Regardless, Mutt should stick to its guns concerning maintaining the security of its users' files. And remember, what we're trading here is the, what, 3 seconds it takes for the user to type "chmod 644 *" (or similar) if they really want to do this. It's a small price to pay for the best insurance available that no one is ever able to read your sensitive mail attachments without you explicitly taking action to allow them to. You'll never be able to blame Mutt for this. -- 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
