Re: PATCH: NSPathUtilities etc

[Richard Frith-Macdonald]

On 8 Mar 2004, at 23:11, Sheldon Gill wrote:

> 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.

I think we can change the implementation in order to make it *more* 
secure
(as long as we keep it reasonably MacOS-X compatible), but we can't make
it less secure as you propose.  It's not an acceptable position to say 
(as you
seem to) that because the existing code is not completely secure we 
should
not be bothering about its security... rather we should be trying to 
improve
its security.  Perhaps we should add code to check that the security of 
the
temporary directory has not been compromised...

> 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"?

That is system dependent ... for any piece of software (such as the X 
server)
temporary files may be stored in a different location ... it's no 
business of
NSTemporaryDirectory() to control interaction with such things.
An application will need to have its own mechanism for interfacing to 
other
pieces of software ... it can't expect the OpenStep/MacOS-X/GNUstep API 
to
know about other applications.

> What about breaking compatibility with OpenStep/Cocoa?

We shouldn't do it ... which is why we must keep the behavior of having 
a
private (to the user) temporary directory as MacOS-X does.

> > > 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...

The code should check that the directory is not accessible by other 
users ...
we need to fix that.

> > 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.

Yes.

> 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.

In my experience it's much better to try to get as much security built 
in as
possible (so we should make NSTemporaryDirectory() thoroughly secure)
as people won't generally use additional non-standard security 
mechanisms.
So we should stick with the MacOS-X behavior, though probably with some
additional checks.

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

It's probably the case that the function should raise an exception if 
unable to return
a secure directory.

Anyway, irrespective of differences in security philosophy, we need the 
private
directory behavior for MacOS-X comptibility.  I think the issue should 
be making
it as secure as possible.  I don't know how to do that on windows, but 
we should
probably check permissions and ownerships for the directory hierarchy 
on posix
systems ... at least the first time the function is called, and perhaps 
every time.
Also we should probably raise an exception on failure rather than 
generating a
log message and returning nil as we do now.