Security Brainstorming

[Rick]

I've talked to Stefan about eventually implementing some sort of script security within the NPC server itself to make scripts less exploitable.

I'm posting this thread to see if I can get some people's ideas for this, as well as to get people interested in it.

Some of these ideas will probably be based on other languages which feature security.


Some ideas off the top of my head:

All variables within an NPC are protected. They can be read by other NPCs, but not written to. Variables can be exposed as public by using some method such as "public variable someVar;". This includes system variables (such as rupees, bombs, etc).

I'm not sure how objects should be handled though, for making them public. If it's made so that if you make an object variable is public, all subproperties are public, then you should be able to explicitly mark subproperties as private. Eg: "private variable someObject.property".

You should not be able to do something like this:

putNPC2(x, y, "public variable someVar; join(\"someclass\");");

As it would be a security breach.

This should include clientr variables as well. Obviously not client variables though (for backwards compatability).

Attributes and ani parameters obviously won't be protected (for backwards compatability reasons).

Functions may only be called by another NPC if they are public, which is how it is now.

System object functions which *modify the object itself* (such as player.setLevel2) may only be called from within that object. Perhaps there can be a way to make these functions public as well. This way we can wrap these functions and do any security checks we need to without worrying about scripts bypassing our custom function and calling it directly.

Functions calls should pass an implicit variable called "sender" or "caller". This can either be an automatic thing (like this/params) or could be an argument. For example:

public function someFunc()
{
  if (sender.name != "someTrustedNPC")
  {
    return;
  }
  
  // do whatever...
}

This way we can validate NPCs that are allowed to call our functions -- or impose stricter limits on some NPCs that don't match our criteria.



Feel free to share your ideas/comments/criticism.

[ApothiX]

Originally Posted by Rick

Functions calls should pass an implicit variable called "sender" or "caller". This can either be an automatic thing (like this/params) or could be an argument. For example:

public function someFunc()
{
  if (sender.name != "someTrustedNPC")
  {
    return;
  }
  
  // do whatever...
}

This way we can validate NPCs that are allowed to call our functions -- or impose stricter limits on some NPCs that don't match our criteria.

I really like this idea, I have tried to mimic this behavior in the past but it was hard to get it to be secure (as I'd have to actually send the name of the NPC along with the call, which is pointless if the 'hacker' can manually send the name anyway)

[Skyld]

Originally Posted by Rick

All variables within an NPC are protected. They can be read by other NPCs, but not written to. Variables can be exposed as public by using some method such as "public variable someVar;". This includes system variables (such as rupees, bombs, etc).

What about one NPC adding a new flag to another NPC?

NPCs could have a set of permission flags modifiable only by that NPC, deciding if all objects in that NPC are public by default, if other NPCs can add new variables, etc.

[Rick]

Originally Posted by Skyld

What about one NPC adding a new flag to another NPC?

NPCs could have a set of permission flags modifiable only by that NPC, deciding if all objects in that NPC are public by default, if other NPCs can add new variables, etc.

Ah, I forgot to mention that. I guess I would say that creating new variables wouldn't be allowed, either.

[Skyld]

Originally Posted by Rick

Ah, I forgot to mention that. I guess I would say that creating new variables wouldn't be allowed, either.

Hm, I think perhaps having an option to either allow or disallow that would probably be more useful.

[Rick]

Originally Posted by Skyld

Hm, I think perhaps having an option to either allow or disallow that would probably be more useful.

Why though...? Would you want a random mad docter to come up to you and start adding weird bodyparts to you? :P

[Skyld]

Originally Posted by Rick

Why though...? Would you want a random mad docter to come up to you and start adding weird bodyparts to you? :P

Depends if said body parts would benefit me.

[Admins]

I would prefer something where you set the rights of the objects, similar to the rights of players. You could define what other variables and objects a special object can access. Also when doing putnpc2 it would automatically transfer its own rights to the new object. You could also define what rights the local npcs of a level have, and eventually also define the rights of a group of objects, and what rights a new npc should have when an admin adds one.
Rights include access rights and deny rights, similar to +rw and -w.

[Skyld]

Originally Posted by Stefan

I would prefer something where you set the rights of the objects, similar to the rights of players. You could define what other variables and objects a special object can access. Also when doing putnpc2 it would automatically transfer its own rights to the new object. You could also define what rights the local npcs of a level have, and eventually also define the rights of a group of objects, and what rights a new npc should have when an admin adds one.
Rights include access rights and deny rights, similar to +rw and -w.

Would function calls fall under +r, or another, say, +x?