On Sat, Oct 24, 2009 at 02:24:40PM -0400, Bill Bogstad wrote: > Great post. I've done something like this, but never saw the idea of > using membership of a group used as a gateway in quite this way before > now. Glad you got something out of it... :) > 1. You seem to have complicated your example somewhat by having an > 'auditors' group. No file or directory in your example is ever placed > in that group. The important thing is that the auditors' accounts are > not in the accnting group and are in the finance group. Right, I alluded to this: > > [Astute readers will note that the case I describe below can be > > optimized a bit. The method below is the most general and assumes > > that neither group is a subset of the other, nor can it be treated > > that way, due to access restrictions on other files not > > considered.] I described it the way I did, because in most real environments, the two groups will indeed have different roles, and the auditors will need control over at least some files that the accountants should not have access to, and vice versa. In my simple example, it works to reduce the number of groups, and put all the users in one group, and only the accountants in their own group. In practice, it's unlikely to work out that way (though it very much depends on the size and complexity of your organization). [...] > Fortunately, there is a mechanism to 'force' group ownership of new > files into a specified group. If you do a 'chmod g+s directoryname' > on a directory all new files/directories created underneath that > directory will be created with the same group as directoryname. > Even better, it seems like any new directories that you create will > have g+s automatically set as well. [...] > sudo chmod g+s /tmp/finance/accounting Indeed, I did exactly that, though I didn't describe why, and the commands I used were different than the ones you suggest: > > [/tmp] $ sudo chmod 2770 /tmp/finance > > [/tmp] $ ls -ld /tmp/finance > > drwxrws--- 2 root finance 4096 2009-10-23 23:41 /tmp/finance/ The leading '2' in the chmod command is what does this (there's a fourth set of bits, represented as the left-most digit, which controls the SUID, SGID, and Sticky bits, in that order). I usually use the numeric representation of the permissions with chmod, because, if you know them in advance, you can set them exactly with one command. Though I sometimes find that modifying permissions is easier to think about in terms of the symbolic method, e.g.: $ chmod a-w foo ...which removes the write bit from all three sets of bits. > mkdir /tmp/secretstuff > chmod 711 /tmp/secretstuff > mkdir /tmp/secretstuff/FunKyPassword > chmod 755 /tmp/secretstuff/FunKyPassword The trouble with this is, if you know that the data exists, even if you don't know *where*... it may not be all that hard to find out. If you know someone who works on that data, it's probably easy enough to walk over to them, make a pretense as to why you're there, and then scan their terminal window. Chances are pretty good it'll be there somewhere, if it's the sort of thing they work on a lot. As you point out, you can also scan ps output, as it may show up if someone is working on a file there and specified the full path, or enough of the relative path to reveal the location. You might well use something like this to secure love notes to your wife (which probably isn't useful unless she has access to your system), but not your company's trade secrets or financial documents... ;-) It is a useful trick though. It prevents users from having a shell with that directory as its current working directory, may slow an attacker down enough to give you a chance to catch them (security through obscurity does have its uses, even if it can not be relied upon solely), and may have other utility. Now, for the bonus round: Under certain circumstances, the method I described fails. When? -- 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.