Re: PATCH: NSPathUtilities etc

[Sheldon Gill]

On Wed, 17 Mar 2004 19:17, Richard Frith-Macdonald wrote:
> On 8 Mar 2004, at 23:11, Sheldon Gill wrote:
> > On Fri, 5 Mar 2004 09:30, Alexander Malmberg wrote:
> >> [snip]
>
> 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...

How stringent should the checks be?

And what happens with -base thinks a temporary directory has been compromised?

I wasn't advocating not bothering about security. I was advocating providing 
security through a layer which could be more easily and closely audited and 
changed to meet particular needs. I tried to provide examples of those 
possible needs to show that a one size fits all implementation isn't the best 
way forward.

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

I was thinking about having the function available as the basis for 
implementing such "mechanisms for interfacing".  When finding the location 
of /tmp is needed for both things I think it best that one routine provides 
the functionality rather than replicating code.

IMHO separating things into two is the right thing. Doesn't matter to me if it 
is GSSecureTemporaryDirectory/NSTemporaryDirectory or 
GSSystemTemporaryDirectory/NSTemporaryDirectory.

Consider that currently NSTemporaryDirectory is used to provide an 
NSMessagePort implementation over unix domain sockets. As the current return 
is supposed to be user only it means that interapplication communication 
using NSMessagePort is only possible for applications running as the one 
user.
So I can't, for example, create a server for all users on the one machine.

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

This was really to show what security is like. It's not a "thing". It's a way 
of life. You don't 'get' secure. You 'behave' secure. Always in all things 
otherwise you are compromising security. Addressing a few infosec elements 
doesn't cut it at all.

No-one else seems to have noticed the  trivial DoS yet...
Or the possible race conditions...

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

I'm so glad you agree. Would have forced the "what is security" debate which 
just would have been bad.

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

I was advocating a gnustep standard security API which could provide 
appropriate behaviours for various cases.  Such an API would be in Additions 
and so provided on MacOS X.

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

I don't think we should check every time.

Properly setting security attributes for windows is quite a complicated thing 
but that shouldn't slow things for posix.

Good checks for ownership and permissions is probably sufficient. The trickier 
question is what to do when those checks fail. How do you avoid races, 
symlink hijacks, DoS...

> Also we should probably raise an exception on failure rather than
> generating a
> log message and returning nil as we do now.

Agreed on this.  Question is what exception and how do we recommend 
applications handle it to degrade gracefully?


Regards,
Sheldon