[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New method to load user bundles
From: |
Richard Frith-Macdonald |
Subject: |
Re: New method to load user bundles |
Date: |
Thu, 5 Jun 2003 18:34:00 +0100 |
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.
- Re: New method to load user bundles, Jeff Teunissen, 2003/06/02
- Re: New method to load user bundles, Tobias, 2003/06/02
- Re: New method to load user bundles, Jeff Teunissen, 2003/06/03
- Re: New method to load user bundles, Alexander Malmberg, 2003/06/03
- Re: New method to load user bundles, Chris Beaham, 2003/06/05
- Re: New method to load user bundles, Richard Frith-Macdonald, 2003/06/05
- Re: New method to load user bundles, Chris Beaham, 2003/06/05
- Re: New method to load user bundles, David Ayers, 2003/06/05
- Re: New method to load user bundles,
Richard Frith-Macdonald <=
- Re: New method to load user bundles, David Ayers, 2003/06/05
Re: New method to load user bundles, Nicolas Roard, 2003/06/02