Re: Creating NSImage in a tool

[Sheldon Gill]

Richard Frith-Macdonald wrote:
> On 16 Feb 2006, at 03:37, Alex Perez wrote:
>
> > Sheldon Gill wrote:
> > > Stefan Urbanek wrote:
> > > > [snip]
> > > There is code in base which enforces a particular security policy.
> > > It seems the security policy on your system violates those expectations.
> > > The specific issue is that your configuration file 'c' has 
> > > permissions on it that base doesn't like.
> > > My recommendation is removing the offending code: gnustep-base 
> > > NSPathUtilities.m ~line 660
> >
> > If this causes problems *under windows*, shouldn't it be ifdefed out 
> > *under windows*?
>
> In plain english, I think what Sheldon is saying is that the doesn't 
> think the base library should check whether the config file it is 
> reading in could have been hacked by someone else or not.

Interesting choice of emotive words here. The implication is that the check can 
determine if the config file is hacked or not. And that failing to check 
somehow would 'open the doors' to hackers.

Unfortunately, the test is *far* from conclusive and actually does very little 
to improve security.

There are many ways to "crack" and the test for a config file having POSIX 
permissions set to no write for 'group' and 'others' hardly constitutes a 
thorough test nor reasonable barrier.

> If so, I strongly disagree with him on this ... if you read in a config 
> file which tells you where programs are located, and someone has hacked 
> that to point to a trojan, you have a big security issue, so this sort 
> of checking is essential.  It is not sufficient to say that developers 
> should add other checks of their own devising (of course that would be 
> good) ... you have to try to minimise security problems at every point.

I'm afraid your security analysis here is deeply flawed.

* You're suggesting that the check is sufficient to detect that someone has 
edited the file to point to a trojan.
Its not.

* You note that "this sort of checking" is essential:
Why then is it not done widely in the unix world?
Why is it not noted in any of the security programming guide?

Seeing that this is essential, I take it you've modified sshd on all your 
machines? And taken this 'security flaw' to OpenBSD?

> So the 'correct' advice would have been to locate and protect this 
> config file such that only the owner could modify it, so that the check 
> would not fail.  Hacking the source as suggested would be a last resort 
> IF Stefan want insecure code.

This amounts to saying that the 'correct' advice is to ignore whatever security 
policy was in place and instead implement the one espoused within the code in 
-base.

The suggestion that "hacking" the source would make the code inherently mode 
insecure is wrong.

> Of course it's never quite that simple ... you have filesystems which by 
> design cannot be made secure ... do we just say config files are not 
> supported on such filesystems?  It's a reasonable answer, but debatable.

I think we say "this file system doesn't support <x> security features"

Just because the file system is insecure doesn't mean that the machine is 
insecure, just as file systems offering enhanced security doesn't by itself 
mean the machine is secure.

> On windows you also have the problem that the security model is not the 
> same as the posix/unix one, and it's possible to have things secured by 
> access control lists even though they appear insecure when you look at 
> posix file modes ... it's a bug that the base library does not check 
> this (and I would love someone to contribute the code to do so) ... but 
> that's a reason to fix the bug, not a reason to make the code less secure.

The trouble is, what ACL constitutes secure and what doesn't?
I guarantee your answer is one of policy, and so not universally applicable.

Just as the current base implementation enforces just one policy, where others 
are just as valid depending on the circumstances.

Note that this ACL complication also applies to *nix with acl support. I take 
it you consider it a bug that the current code does nothing to detect acl 
support and check attributes on *nix?

For this particular case of base security policy enforcement:

* base will refuse to run if the POSIX permission are not ?????-??-?
this opens the way for a denial of service if you can change those permissions
this opens the way for a user to deny themselves if they change those 
permissions

* a cracker can change ownership of the file and still point it to a trojan

* a cracker can edit the file and point it to a trojan

* a cracker can replace gnustep-base with a trojan version and *not* touch the 
config file at all

* code is on critical startup path for just about *every* application and tool 
so its slowing down everything

* more code = more complexity and more maintenance

* code fails to deal with acl, trustees and other enhanced security models

* it enforces just *one* policy, imposing it on all users and denying them 
flexibility in administering their systems.


IMHO the costs greatly outweigh the benefits.


Regards,
Sheldon