Messages in this thread | | | Date | Wed, 28 Oct 2009 22:07:05 -0700 | From | Casey Schaufler <> | Subject | Re: symlinks with permissions (fwd) |
| |
Pavel Machek wrote: > (I forgot to cc the list) > > From: Pavel Machek <pavel@ucw.cz> > To: "Eric W. Biederman" <ebiederm@xmission.com> > Subject: Re: symlinks with permissions > X-Warning: Reading this can be dangerous to your mental health. > > Hi! > > >>>>> Part of the problem is that even if you have read-only >>>>> filedescriptor, you can upgrade it to read-write, even if path is >>>>> inaccessible to you. >>>>> >>>>> So if someone passes you read-only filedescriptor, you can still write >>>>> to it. >>>>> >>>> Openly if you actually have permission to open the file again. The actual >>>> permissions on the file should not be ignored. >>>> >>> The actual permissions of the file are not ignored, but permissions of >>> the containing directory _are_. If there's 666 file in 700 directory, >>> you can reopen it read-write, in violation of directory's 700 >>> permissions. >>> >> I can see how all of this can come as a surprise. However I don't see >> how any coder who is taking security seriously and being paranoid about >> security would actually write code that would have a problem with this. >> >> Do you know of any cases where this difference matters in practice? >> > > Actually yes, see the bugtraq post. guest was able to write to my file > when I expected that file to be protected. > > According to the bugtraq discussion, people expect directory > permissions to work.
Gawd, I hate to say this, but people have been improperly educated if they expect directory permissions to behave thusly. You can not count on the permissions on a directory to protect access on a file that the directory contains a reference to. Hard links. Mount points. /proc/8675309/fd. Passing file descriptors over sockets. Fork, for heaven's sake. That's not how Linux directories really work.
> /proc currently breaks that. I bet there are few > systems in the wild that have permissions set up like that, but it is > not easy to actually find such systems. > > Better fix it... > Pavel >
Well, /proc/8675309/fd is a silly notion, but it's been around long enough that you are going to have trouble getting rid of it and doing so wouldn't solve the "problem" in any case.
| |