On Fri, Jun 26, 2015 at 06:06:50PM +1000, Erik Christiansen wrote: > On 25.06.15 11:48, David Champion wrote: > > There are use cases for allowing specific roles/service accounts > > access to your unvetted email attachment files. (I would expect these > > generally have to do with file sharing/export.) Conventionally the only > > way around this is to proactively degrade your data security and allow > > world (or group) access. > > If the attachment is written with unprivileged permissions, then it can > hardly be a greater security threat than any other harmless file a user > might write. I.e. If the OP were to create attachment files with his > ownership, no execute permissions, and some group to which he belongs, > then where's the risk?
In the case of a role account, it's probably fine... probably. Assuming no one ever misuses the role account and sends things meant to be private to it (which I can almost guarantee you WILL happen, at some point). Otherwise... Suppose you are a team leader, working for Evil Corp. You receive an e-mail from your boss with an attached document detailing how Evil Corp plans to kill a number of its employees due to the discovery that they have been engaged in espionage against the company. You, as their team leader, have been tasked with eliminating a couple of your team members. That's an attachment you definitely don't want your team seeing! Obviously, this is an extreme and contrived example, but suppose instead you are working at an intelligence agency, or a government contractor, a start-up with a new idea, or any company engaged in market-breaking research, etc.. Those organizations are built on secrets to at least some extent, and controlling who has access to them is critical to their success. For someone with the requisite knowledge and access, it's actually fairly simple to create a program to watch the team lead's attachment directory, and steal the contents... the files need only be readable for however long it takes the system to copy them. > It exists to be used, and serves well to provide broader access > _without_ unnecessarily compromising security. If group access is > granted, then it is because group access is required. It cannot then > be a degradation of security. Many, many compromises have resulted from the fact that you are simply wrong. :) Most often security is compromised because the thing being protected is misclassified, or the people under its protection are annoyed by the inconvenience and do not understand the consequences, and so circumvent the proscribed protections. You should have seen the look on my former CEO's face when, shortly after my coworker and I were hired, we told him we could mount his mail spool on any desktop in the company... I am not making this up! > (I have used it for years on source code repositories to securely > determine who had access to what parts of the code base.) Sure, that's a great use for group permissions. But that hardly means that group should have access to absolutely everything that you do... or every attachment you save, even briefly. > drwxr-srwx 2 root mail 1024 Jun 26 17:33 /tmp/test > > $ touch /tmp/test/fred > $ ls -l /tmp/test/fred > -rw-r--r-- 1 erik mail 0 Jun 26 17:33 /tmp/test/fred [...] > That much, at least, is pretty simple. Is there a case for the OP > needing more? What you're missing is that Mutt explicitly opens the files for the attachments it creates with 0600 permissions. So while you're right that this will set the GID of the files that are saved there, the group will still not be able to access them until the owner uses chmod on them. Which is a Good Thing™. -=-=-=-=- Incidentally, it's often not understood that group perms can be used to take away access... For instance, say the file you just created had these permissions: -rw----r-- 1 erik mail 0 Jun 26 17:33 /tmp/test/fred In other words, world-readable but the group mail has no access. In that case, anyone in group mail will NOT be able to read that file, with the exception of erik. Permissions are checked in heirarchical order, i.e. user (owner), group, and then other. The permissions applied to a particular user are those from the first class that match the user's credentials. -- 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.
pgpBslm0uCbog.pgp
Description: PGP signature
