[Opensim-dev] secure_inventory_server ??

liu xiaolu lulurun at gmail.com
Fri Jul 25 14:30:05 UTC 2008 

Comparing "pull" and "push", I would like to say:
pull is "require setting a lot of urls on different servers anyway", but
push is full with vulnerability.

the reason is:
I can take control of UserA's inventory by following steps:
* I setup a fake userserver
* I know user A's uuid
* I ask my fake userserver to push a session_id(which is known by mysellf)
to the target inventoryserver
* then I request delete_inventory(session_id, A.uuid)

=> inventory has to rely on 1 or some userserver.

regard,
lulurun

2008/7/25 Michael Wright <michaelwri22 at yahoo.co.uk>:

> Yeah when I suggested the option on inventory server, I just meant so it
> didn't do any checks. The actually intererfaces having a few changes is
> nothing. Everyone has to expect those sort of changes.
>
> Anyway at first I was only suggesting a temporay option. As while everyone
> should expect painful breaking changes, if we can easily add temporary
> options that give a bit of time to change over to a new system then I think
> we should. Again it has to be a easy thing to add, I'm not suggesting that
> we should spend lots of time on adding these options. But like in this case
> a small flag around the security check.
>
> Anyway, if we add the option to the inventory server to turn off checks, so
> that it is no longer tied to a user server. Then there should be no problems
> with removing the region side option. Just with that system in the inventory
> server, we need one option or the other.
>
> I think the sessionId could be made to work, just with a push method from
> the user server rather than a pull. In general I think we should avoid those
> pull systems that require setting a lot of urls on different servers anyway.
>
> So maybe one way would be when the user logs in, it looks up the inventory
> server url that user is using. Then it does a initial request to the
> inventory server to authenticate that grid can have acess to the users
> inventory on that server, which can include the session id.  So really the
> same system but with push rather than pull.
>
>
> *Justin Clark-Casey <jjustincc at googlemail.com>* wrote:
>
> Michael Wright wrote:
> > a quick follow on, what I mean about it being too rigid, is that by
> > having a set userserver set url in the inventory server. It makes it
> > harder to use the same inventory server on multiple grids. Either for
> > the same user (if their id on each grid was the same). Or just multiple
> > grids/user groups sharing a common inventory server.
> >
> > I actually consider both of them features that we have/had and should
> > keep. SO while on important bug (the lack of security) has been fixed,
> > it has broke two other features.
>
> I do agree. In the long term I think that security for the inventory
> service should be managed by direct client login
> rather than being tied to a user session id.
>
> However, I suspect that with the current client, user session id might be
> the best that we can do. But I see that to
> preserve the use cases you describe we should have an option to stop the
> inventory server contacting the user server to
> perform security checks. So I'm dropping the concerns I had with putting
> another option on the inv server :-)
>
> However, I think that this switch should simply mean that checks aren't
> performed. It would be much nicer not to have
> it set up a different bunch of 'legacy' handlers instead of the 'secure'
> ones. I think that we should also still
> eliminate the old InventoryService option on the region server as soon as
> possible to avoid the dead weight of that code
> and needless option proliferation - if people are following trunk then they
> really do have to expect that there are
> occasionally going to be painful breaking upgrades.
>
> >
> > */Michael Wright /* wrote:
> >
> > Okay had a bit deeper look at the inventory changes, and see the
> > changes aren't anywhere near as big as I was imagining. So guess I
> > take back my suggestion of a option.
> >
> > I made the suggestion, because my thinking in something like while
> > no interfaces are going to be anything like stable until much nearer
> > to 1.0, I do think if a really big change is made to a interface
> > (specially on the interfaces to the grid servers). If it is possible
> > to add a mode for backwards compatibility easily, then we should do
> > so (even if only temporary). But as I said, after looking more
> > closely at the changes, doesn't look like this is such a big change.
> >
> > I'm a little concerned about the constant lookup to the user server.
> > As I think really we should be trying to spearate the
> > inventory/asset servers so they are more standalone (don't keep
> > connecting to other servers). To allow for a more destributed set up
> > with them. But haven't really thought about how a secure system
> > could work there. This lookup method just feels a bit too rigid to me
> >
> > */Michael Wright /* wrote:
> >
> > Yeah I guess, one problem with changes like this is anyone who
> > has custom Login service (like us) has to rewrite it to use the
> > new methods. Which is going to take time. But I guess that is
> > how things go.
> >
> > To be honest, even not taking that into account I would still
> > like to see a way to turn things off. While you can argue that
> > we should avoid too many options. At the same time I think you
> > can argue that we should make things as customisable as possible
> > (which is what I prefer).
> >
> > I guess I need to look at the changes in inventory server more
> > closely before I can really give a proper opinion though.
> >
> > */Justin Clark-Casey /* wrote:
> >
> > Michael Wright wrote:
> > > We might also want to add a temporary config setting to
> > the inventory
> > > server to turn the security off. For people who want to
> > update the
> > > server, but could have old regions on the grid.
> >
> > To be honest, I think that it would be nice to avoid option
> > proliferation. Already, the 'secure' option is really just
> > a bridge - the original mode should be removed (and secure
> > become the 'default') when we're happy that they aren't major
> > difficulties. Adding another option for inventory server
> > potentially exposes another point of failure and something
> > that will have to be deprecated/removed later on.
> >
> > I think that traditionally we've been happy to have breaking
> > grid changes that have required region updates. Can we do
> > the same thing here?
> >
> > >
> > > */liu xiaolu /* wrote:
> > >
> > > OK, I can understand that,
> > >
> > > you can change the OpenSim.ini.example like,
> > > add the following line inside [Network] section (just under
> > > inventory_server_url):
> > > ;secure_inventory_server = true
> > > you should keep the line commented, because by default
> > its value is
> > > "true"
> > >
> > > We(Johan, Mikem, lulurun) discussed about this,
> > > "secure_inventory_server" is just a "bridge"
> > > for the people who are running latest regionserver, but
> > using old
> > > revisions of UGAI.
> > >
> > > as the revision number grows, we want to delete this
> > option in the
> > > short future.
> > >
> > > \\\\
> > > 2008/7/25 Charles Krinke >:
> > >
> > > Thanks, Lulurun. That helps some.
> > >
> > > I believe the concern I have is the support of our users
> > on the
> > > #opensim IRC channel. If there are settings to OpenSim
> > that are
> > > *not* in OpenSim.ini.example and someone sets them, then
> > support
> > > gets more difficult.
> > >
> > > At this point, I am merely trying to suggest that any config
> > > settings that anyone might use be entered in
> > > OpenSim.ini.example. Additionally a couple of comments that
> > > describe when one might want to use these settings would help
> > > our users move forward.
> > >
> > > Charles
> > >
> > >
> > > ----- Original Message ----
> > > From: liu xiaolu >
> > > To: opensim-dev at lists.berlios.de
> > >
> > > Sent: Thursday, July 24, 2008 8:04:24 PM
> > > Subject: Re: [Opensim-dev] secure_inventory_server ??
> > >
> > > That option is avaliable from 5592, it is just a
> > temporary thing.
> > >
> > > To explain the situation simply:
> > > 1. old inventory server accepts any request without check the
> > > use identity, this causes a problem that everyone's inventory
> > > information can be easily modified by other people who
> > even do
> > > not know your password.
> > > 2. secure_inventory_server accepts request by checking a
> > valid
> > > session_id, so every inventory request needs to be attached a
> > > session_id.
> > > 3. then both of the regionserver and the inventoryserver
> > have to
> > > be changed:
> > > 3.1 regionserver adds user's "session_id" to inventory CRUD
> > > requests
> > > 3.2 secureinventoryserver expects the request data contains a
> > > "session_id"
> > > 4. so the latest regionserver do not work with non-secure
> > > inventoryserver any more.
> > >
> > > the option enables people who are using the latest
> > regionserver,
> > > but want to connect to a non-secure inventoryserver -
> > they can
> > > set "use_secure_invnetory" to false in OpenSim.ini
> > >
> > >
> > > 2008/7/25 Charles Krinke >:
> > >
> > > I am hearing about a new OpenSim.ini setting called
> > > secure_inventory_server and am told it is not in
> > > OpenSim.ini.example. I believe all settings for OpenSim
> > > should be in OpenSim.ini and have a default, which in this
> > > case could be either true, or false, I would think.
> > >
> > > Can someone please help us understand what this setting is,
> > > what it does when set to false, what it does when set to
> > > true and perhaps consider adding at least a default for this
> > > setting in OpenSim.ini.example?
> > >
> > > Charles
> > >
> > > _______________________________________________
> > > Opensim-dev mailing list
> > > Opensim-dev at lists.berlios.de
> > >
> > > https://lists.berlios.de/mailman/listinfo/opensim-dev
> > >
> > >
> > >
> > >
> > > --
> > > Lulurun
> > >
> > > _______________________________________________
> > > Opensim-dev mailing list
> > > Opensim-dev at lists.berlios.de
> > > https://lists.berlios.de/mailman/listinfo/opensim-dev
> > >
> > >
> > >
> > >
> > > --
> > > Lulurun
> > > _______________________________________________
> > > Opensim-dev mailing list
> > > Opensim-dev at lists.berlios.de
> > > https://lists.berlios.de/mailman/listinfo/opensim-dev
> > >
> > >
> > >
> > ------------------------------------------------------------------------
> > > Not happy with your email address?
> > > Get the one you really want -
> > > millions of new email addresses available now at Yahoo!
> > >
> > >
> > >
> > >
> > ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > Opensim-dev mailing list
> > > Opensim-dev at lists.berlios.de
> > > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
> >
> > --
> > justincc
> > Justin Clark-Casey
> > http://justincc.wordpress.com
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
> >
> > ------------------------------------------------------------------------
> > Not happy with your email address?
> > Get the one you really want
> > - millions of new
> > email addresses available now at Yahoo!
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
> >
> > ------------------------------------------------------------------------
> > Not happy with your email address?
> > Get the one you really want
> > - millions of new email
> > addresses available now at Yahoo!
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
> >
> > ------------------------------------------------------------------------
> > Not happy with your email address?
> > Get the one you really want -
> > millions of new email addresses available now at Yahoo!
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
> --
> justincc
> Justin Clark-Casey
> http://justincc.wordpress.com
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
> ------------------------------
> Not happy with your email address?
>  Get the one you really want <http://uk.docs.yahoo.com/ymail/new.html> -
> millions of new email addresses available now at Yahoo!<http://uk.docs.yahoo.com/ymail/new.html>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>


-- 
Lulurun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080725/7891913d/attachment-0001.html>

More information about the Opensim-dev mailing list