Client side Whitelisting is to restrictive. about vircadia-native-core HOT 7 CLOSED

Not extremely intuitive to figure, but I see where you go.

So why not an "Entity Script White List" group of attributes on the zone Entity (Like we have for Keylight, Haze, etc.)
It could be easier to manage.

from vircadia-native-core.

This is a really good thought and has been brought up before.

I suppose the question is... How should we approach this at current? One such idea was to place an entity close to wherever a user enters the domain at that has a list of the script URLs to whitelist in it, then it is the domain owner's responsibility to lock it and make sure no one with lock/unlock rights changes that for malicious purposes.

Then basically the client will auto pass those scripts for that domain.

It would also be necessary to make sure no one spoofs that secured object on a public building domain.

from vircadia-native-core.

Eventually, and hopefully sooner rather than later, I'd like to see the interface behave more like a web browser when it comes to script security. The hurdle there is that we need to replace the Qt script engine with something that has support for security contexts like V8. This way we can run scripts hosted by a domain in a trusted manner in one context, and foreign scripts in a less trusted context.

from vircadia-native-core.

Keb, that does seem like a good idea to go with. Being spatially aware instead of domain-aware to determine what scripts run in what context (pass or fail.)

@MarcusLlewellyn that would for sure be a nice way to go once we get that going WRT V8. However, is it not trivially possible for the client to receive that list of trusted domains from the host domain and run them by default? I suppose that's what we're doing by this zone method, and ideally I think using the zone method + a whole domain list would be good because then it allows for better subleasing later since others can elevate their own domains in their own sub-spaces.

from vircadia-native-core.

I wonder how it would works...
When we enter in a zone, the entities might be already loaded (currently I think they are), but their script get initially refused to run. Are we going to re-check if some of them need to be started? (Doing this may be not very performant.)

I think we better get this white list at the second we enter on a domain, (from the server), before it starts to deal with scripts. So have this configured on the server.
Can't we call the server to get that list?

from vircadia-native-core.

#112

Whitelist is now disabled by default, it has a toggle to enable or disable. Though ways to have the server send a list of trusted domains to the client will still need to be implemented. Probably would not be the hardest thing in the world to do, but that transfer of information needs to be had and registered before the domain's entities load.

from vircadia-native-core.

Closing this issue for now because PR 112 takes care of this, if still desired, it would be best to open a PR about expanding the whitelist security capabilities by having security contexts and communication passed from the server, or other ideas like that. :)

from vircadia-native-core.