discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Creating NSImage in a tool


From: Sheldon Gill
Subject: Re: Creating NSImage in a tool
Date: Thu, 16 Feb 2006 17:50:24 +0800
User-agent: Thunderbird 1.5 (Windows/20051201)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]