Approximately Thu, May 20, 2010 at 1:48 PM, Ted Stern
<[email protected]> wheedled:
> Let's say that I want to restrict access to a directory hierarchy
> under 'mytopdir' to members of a particular group 'mygroup', on a
> Linux ext3 filesystem, running kernel version 2.6.x or higher.
>
> (1) Is it sufficient to change the permissions of the top level
> directory to 750 and the group to mygroup?
>
> chgrp mygroup mytopdir
> chmod 750 mytopdir
Yes, with two exceptions:
* if someone not in mygroup is in mytopdir or a subdirectory
thereof right now before you fix the perms, they are still
there and will have access to what the new perms allow.
e.g. if mytopdir/sekrit were still 755 and they were
in it, they still can 'ls' and friends.
Once they chdir out, they're out for good.
You probably don't care about this edge case. Use 'lsof' as root
to see if anyone's in there after your chmod if you are a good
paranoid citizen.
* you export a subdirectory via other means, e.g. nfs/smb/etc.
depending on the setup it may bypass the mytopdir perms.
> (2) Or must the permissions and group ID be set all the way down
> through the directory hierarchy (with a setgid bit set on directories
> to ensure the same group ID for new files)?
I prefer to do this, but it's not required.
> In the first case, I could envision some program (e.g. e2fsck and/or
> debugfs) that is able to access the inode of an unprotected lower
> level directory and then access the files in that directory.
Anything device/block level would require root, game already lost.
> But as far as I can tell, any /sbin program of that sort requires
> root-level access to play with the filesystem that way, and if you
> have root-level access you might as well traverse the filesystem
> without worrying about inode hacks.
ding.
> Question: Is (1) a secure enough method, assuming that root hasn't
> been compromised and that a hacker or malicious user isn't a member of
> 'mygroup'?
Yep. But I prefer doing it all the way down the stack for the
reasons above as well as your following note:
> I have been recommending approach (2) to users to avoid even the
> *appearance* that access-controlled files do not have restrictions [it
> is also helpful in the event that a subdirectory is copied somewhere
> else in the filesystem] but there are cases in which (1) would be the
> only practical approach, for example if you want to enforce that a
> user must be a member of two groups:
If I'm in mytopdir/subdir1/subdir2 and I see that dirs are 0750
for a group I'm in and my friend isn't, I'm going to see that
easily and not invite him to look at the restricted things. If
everything looks 0755 I'm not going to check all higher paths
until I tell him to look at the death star plans and wonder why
it's not working for him.
--
Bri Hatch, Systems and Security Engineer. http://www.ifokr.org/bri/
"At some point we all need to pay for what we do. Your time is now."
