Re: PATCH: NSPathUtilities etc

[Sheldon Gill]

On Fri, 5 Mar 2004 09:30, Alexander Malmberg wrote:
> [snip]
>
> NSTemporaryDirectory has been implemented and _documented_ as returning
> a secure, this-user-only directory for a long time. Both code in GNUstep
> and outside GNUstep depends on this. Changing this would break things
> and introduce subtle security holes and information leaks.

Relying on a 'secure' directory and creating insecure files there is a recipe 
for disaster in most cases.

I'm convinced we can change the implementation without breaking anything 
within GNUstep.  As for code outside, at worst it will require a find/replace 
to fix. Put an explanation into the release notes.

Security needs to be considered, not glossed over by assumption. Saying "I've 
got a firewall so I'm secure" doesn't cut it. We all need to realise that and 
work accordingly.

Consider also, if a user activates a worm/virus/trojan or a buggy application 
then it can access all the files in the 'secure' directory. This hole can be 
avoiding by using an appropriate ACL, file locking or capability mechanism.

IMHO the consequences of this change aren't as dire as you believe.

> IMHO, it'd take _extreme_ reasons to change documented behavior with
> such consequences. For this reason, if no other, I think the behavior
> should remain as it is.

So how does an application discover where temp is for other reasons like 
"/tmp/.X11-unix" and "tmp/kde-sheldon"?

What about breaking compatibility with OpenStep/Cocoa?

> > Firstly, the existing code isn't really secure. You can circumvent it.
>
> Then that should be fixed. How is it broken?

Create /tmp/alexander with 0777. Anyone with local access can do it...

> At a quick glance, it seems ok (on posix systems) aside from not
> returning nil if the directory creation fails (at least it logs in that
> case). I'll fix that tomorrow.

Security is an involved and complex subject that needs more careful 
consideration.

I really advocate going for the OpenStep Standard behaviour and layering 
security choices on top. For starters, it will highlight code dealing with 
security issues making focus and review a lot easier.

Also: try replacing NSTemporaryDirectory() with an implementation returning 
'nil' and running applications.  Watch things break in interesting ways...

> > I
> > looked at changing that but things start getting quite complex.
>
> GNUstep needs a secure temporary directory in a couple of places, so we
> have to solve it anyway.

Within GNUstep NSTemporaryDirectory() is called by:
NSMessagePort.m
NSMessagePortNameServer.m
NSPrintOperation.m

The last one calls it to create a temporary file for the print operation. The 
perms for the file should be 0600 and it doesn't matter if it's in a 
sub-directory or not.

The first two are there for a unix domain socket based implementation of 
message ports. Under Darwin and OpenStep it's actually a Mach port wrapper. 
The key functionality is local IPC and there are other more efficient methods 
on many platforms.

We can easily address the requirements for the NSMessagePort implementation in 
this cycle as part of the "upgrade".
 
As for other applications:
StepTalk calls it in one place.
ProjectCenter uses it for the rootBuildPath, in one place.
GWorkspace uses it for the PdfViewer. It's handling of temporary files needs 
more careful consideration from a security persective. Probably 
non-exploitable anyway.
EasyDiff calls it in one place for a single temporary file.


Regards,
Sheldon