Re: GNUstep introduces a serious security problem

[Robert J. Slover]

Exactly.  The file's permissions govern what can be done to the  
contents of the file.  The directory's permissions govern what can be  
done to the contents of the directory.

In ancient unix systems, the directory listing was an ordinary file  
that could be edited directly in your favorite text editor.  EMACS has  
a directory editing mode that simulates that behavior on modern systems.

On more modern systems, you may also have the further complication of  
ACL's (Access Control Lists), which may modify the actual permissions  
to something other than what you see when you do an 'ls'.

Richard is correct, though, and others also -- access control is the  
responsibility of the OS, and any problem you would find here would be  
a bug in the OS or any libraries it may use to implement custom access  
control policy.  This is the only "correct" way to do things --  
leaving the proper behavior up to individual applications would make  
it blatantly easy for rogue applications to ignore inconvenient  
permissions.

Understanding this behavior is very important too.  You may make a  
file read-only to protect it, but someone with permission to modify  
the directory containing it and to read the file might still copy it  
elsewhere, remove it, and put a changed copy back into place.  This  
generally leaves evidence (changed ownership), but if the file is  
sufficiently important, successfully modifying it might then allow  
enough privilege escalation to remove that evidence after the fact.  I  
actually once needed to (for legitimate reasons) exploit this behavior  
on a machine at work where I could not edit files I needed to because  
they were accidentally put into place on the NFS server with ownership  
belonging to root, but root squashing was turned on in the NFS server,  
making me 'nobody' as far as the server was concerned if I tried to  
become root.  I didn't have root access to the NFS server directly,  
either.  As myself, I did have permissions to remove the entire  
directory containing these files.  Tar the directory up, remove it,  
untar it and watch tar complain that it can't set the ownership, and  
viola!, I'm now owner of it and everything it contains.  Problem solved.

--Robert


On Mar 18, 2009, at 3:06 AM, Richard Frith-Macdonald wrote:

> On 17 Mar 2009, at 23:31, Tim Kack wrote:
>
> > Hi Igor,
> >
> > I opened bug #25904 for this, please add the findings to that if  
> > needed.
> > I will check more on this tomorrow.
> > Note, this is not a security issue - it is only the owner that can  
> > touch the file, but it can lead to overwriting data that you didn't  
> > want to have overwritten. A nuisance of course.
> > GNUstep is not using anything that can override the operating  
> > systems permissions checks, it is all built upon standard base  
> > libraries (glibc etc).
>
> It turns out that there is no issue/bug here.  The example/test code  
> was asking to replace an existing file, and the library was doing  
> that.
> On Unix-style systems, if you want to protect a file so that it  
> cannot be replaced, you have to change the permissions of the  
> directory containing the file, not those of the file itsself.
>
>
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnustep