Re: New method to load user bundles

[David Ayers]

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.

First, it is user specific, which means each user must somehow securely 
set the initial values.  Second, the defaults system can be easily 
manipulated with scripts.  Third the user generally has every right (and 
sometimes the need) to delete all of his defaults.

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

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.

I must admit, that I have the impression, that this is more trouble than 
it's worth. 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" :-)

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.