Re: New method to load user bundles

[Richard Frith-Macdonald]

On Thursday, June 5, 2003, at 05:41  pm, David Ayers wrote:

> Richard Frith-Macdonald wrote:
>
> > Secondly, we might want to provide facility to keep track of changes 
> > to bundles (eg store the bundle location and
> > an md5 digest of it in the defaults system) and provide a callback 
> > facility (with a standard panel built into the gui)
> > to alert the user about changes to bundles that are about to be 
> > loaded, and let them accept/refuse the load.
>
> Hello Richard,
>
> Eventhough I tend toward "this is not a GNUstep issue but a general 
> security issue", I have no real objections in adding such security 
> features (except that they may give a false sense of security and 
> could be hard to maintain).  I am a bit concerned though, if this 
> information is stored in the defaults system.

I only suggest the defaults system because the NSUserDerfaults class 
already checks that the defaults database is not writable by other 
users ... so it's relatively secure and simple to implement that way.

> First, it is user specific, which means each user must somehow 
> securely set the initial values.

Yes ... that's the point.

>  Second, the defaults system can be easily manipulated with scripts.

Is that an advantage or a disadvantage?  I think it's probably neutral.

> Third the user generally has every right (and sometimes the need) to 
> delete all of his defaults.

Yep ... seems reasonable.  Do you think it's a problem that a user 
could delete defaults and need to re-authenticate any insecure bundles? 
 I don't see that as any worse than having to re-set any other defaults 
they had set up.

> I think, if we have any authentification mechanism at all, it should 
> be based on something "root owned" with possibly some API for a user 
> to request authentification for a given bundle/library/framework/... 
> for a particular user.  And this API should be password protected 
> (using the user account).

I'm not quite sure what you mean ... perhaps you are taking about 
something quite different from what I suggested ... more like having 
bundles signed  by some certification authority?

All I'm suggesting is a simple mechanism to make sure the user doesn't 
(without knowing about it) load a bundle that some hacker has been able 
to modify because the file permissions/ownership are wrong.  Building 
in a signing mechanism for the original authors of bundles would be 
much stronger security,
but also a lot more work.

> If we do this, would we also provide some "callback" mechanism for 
> tools?  If so, how would the callback for services like gsweb apps, 
> gdomap (or the potential authentification service itself look like?)  
> If we don't, would we actively protect tools at all?  If so, I guess 
> they would simply just not load any non-authenticated code.

Most tools don't go loading insecure bundles ... so I'd suggest not 
bothering to set the callback for them.  We could provide a callback to 
prompt the user for permission on the terminal I suppose, and use that 
for some tools.

> I must admit, that I have the impression, that this is more trouble 
> than it's worth.
I'm sure that depends on who you are.  If I was running a multi-user 
system with lots of relatively untrusted users (eg a machine at a 
university), I'd probably want something like it.

> And I'm not convinced it is a "must have".  But feel free to prove me 
> wrong with the "unbreakable free easy-to-maintain security mechanism" 
> :-)

I wasn't promising to implement it!

> Cheers,
> David
>
> PS:  Maybe the simple approach to address the issue at hand, is to add 
> a configure/make option to simply (hard-codedly) limit the places that 
> bundles are loaded from.  This doesn't add any real security but it 
> satisfies the original request (How can I turn this feature off) and 
> seems simple to maintain.

I don't like compile time settings to lead to a proliferation of 
different versions of GNUstep ... also, while turning the feature off 
was indeed the original request, it doesn't solve the problem... the 
new method to load bundles really just brought an existing security 
weakness to our attention.

For example, if you use an app whose resources directory is world 
writable, the bundles inside it could be hacked to do damage even 
though the bundle would be being loaded from a 'known'  location.

I would consider a bundle to be 'secure' f it's owned by you and 
protected so only you can modify it, or if it's owned by root (or a 
gnustep system manager group) and protected so only they can modify it. 
 You would only be asked for permission to load 'insecure' bundles ... 
those where ownership/permission means that someone could tamper with 
them.  Of course, this assumes that the bundle was not already hacked 
before it was installed.

In an ideal world, we would supply installer packages containing md5 
digests of the apps and have an installer which would check that the 
app corresponded to the digest, and the digest matched the published 
one on a trusted site.  That way you would know you had installed the 
correct app, and any bundles in it would be 'secure' (ie not modifiable 
by anyone else).

Again, I'm not volunteering to do this ... but it would be nice.
I consider GNUstep relatively insecure as packages go, and it would be 
nice if instead it was a very secure system ... but these are not the 
only issues which would need work.