Re: New method to load user bundles

[David Ayers]

Richard Frith-Macdonald wrote:

> On Thursday, June 5, 2003, at 05:41  pm, David Ayers wrote:
>
> > 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.

M'kay...

> >  Second, the defaults system can be easily manipulated with scripts.
>
> Is that an advantage or a disadvantage?  I think it's probably neutral.

Well I think it *good* for the defaults system in general, I think it's 
a bit /dangerous/ that a malicous script (which is even simpler than 
malicoius a bundle) can set alter the /secureity/ information with a 
simple defaults write NSGlobalDomain.  But I guess malicous code is 
malicious code, indiffernt if it's a bundle or a script.  So it doesn't 
give me high blood presure.

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

OK.

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

Yes, I guess I was.  The authority being "root" or a "root" service that 
does the authentification upon request of the user, after the user 
authenticated himself as sudo does.

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

I didn't mean the orignal author but rather the system administrator and 
the user.

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

In general I agree, but I don't see it being GNUstep specific.  It 
should be solved at a different level. (Not that I have any wise ideas 
to allow user installed code and still insure secureity.)

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

Sorry, :-) I mistakingly got the impression, you were considering 
implementing it.

> I don't like compile time settings to lead to a proliferation of 
> different versions of GNUstep ...

Agreed.

Cheers,
David