Please Consider Your Security Model Carefully
Coaldust Numbers
I suggest looking into the capability security model ( https://en.wikipedia.org/wiki/Capability-based_security ) and powerboxes ( https://en.wikipedia.org/wiki/File_dialog#Powerbox ).
The gist is access is controlled via references. "Reference" in this context means what the average programmer thinks it does, memory-safe pointers like references in Java or Python, though they can be implemented in other semantically-equivalent ways. References can be 'given' (passed to your code) but not 'taken' (hence the slogan "there is no ambient authority"). It is difficult to hack or infect what you cannot access!
Powerboxes are like the standard dialog boxes we are all used to that let us do things like open or print files, only they grant permission to do something in addition to designating which thing to do it to (hence the slogan "designation is authorization"). Powerboxes let you securely do the things people do in insecure systems with ambient authority. It is important that powerboxes be impossible to unintentionally answer, which is usually achieved by having them ignore input for a short time after they appear so that users do not mindlessly click "Okay" or "Yes" and they do not accidentally answer them by having their typing elsewhere redirected to the powerbox.
Most permissions should be single-use. For example, I may want to give some poseball the ability to animate me once, but I probably do not want to let it animate me forever after. This is achieved via passing facets ( http://wiki.erights.org/wiki/Walnut/Secure_Distributed_Computing/Capability_Patterns ), which are essentially classes using the Gang of Four proxy pattern to cause an error upon an attempt to use them when certain conditions are met, almost always after a single use or when explicitly revoked.
Client-side scripts can be made secure by using installation endowments ( https://www.cs.jhu.edu/~seaborn/plash/html/shell-inst-endowment.html ). This is essentially a powerbox that asks the user to grant the permissions a program always needs for basic functionality (e.g. to read its own files). It is a part of the user designating what to install, which they would have to do in any system. It can be adjusted (for permissions that are a range or finite set) or revoked (e.g. by uninstalling the program) whenever the user desires by browsing their installed programs. They should use other powerboxes for anything not in their installation endowment.
Please also consider fixing the space and time exhaustion attacks.
To prevent space exhaustion, have a RAM quota per user and per plot and ask the programmer how much RAM their script should receive when it is rezzed. Running out of RAM quota would simply prevent the object from rezzing, preferably with a notification to the user so that they understand why this occurred. Plots that allow someone other than the owner to rez objects, like sandboxes, probably need to allow the owner to divide RAM among each resident (if any) and guests. This solves the problem of users using up all the RAM in a simulator by rezzing an infinite amount of scripts. Users can only waste their own RAM quota.
To prevent time exhaustion, use a nested round-robin scheduler. Each simulator's scheduler rotates through each user and plot. To select a script to run, it rotates through each script attached to that user or rezzed on that plot. This solves the problem of users using up all the processing time in a simulator by rezzing an infinite amount of scripts. Users can only waste their own processor time.
Log In
Kathrine Jansma
> Users can only waste their own processor time.
This is probably a too simplistic design for a system where the simulator that expends those resources is rented by one user or a group of users. The owner of the parcel should have absolute priority for running scripts, even if it hampers scripts used by visitors. After all, the owner can set the parcel to "no scripts" too.
Coaldust Numbers
Kathrine Jansma
The amount of RAM and number of time slices (before the scheduler rotates to the next plot) delegated to a plot should probably be based on the proportion of the land in the simulator that plot makes up. This is the way prim quotas already work.
It would be reasonable to extend my design above to allow the plot owner to specify the number of plot time slices (minimum 1) to dedicate to each resident (people who live there, including the owner) and guests (everyone else). This should probably be a part of the same GUI window you use to specify the RAM (and prims) to delegate to the same people. This is only a concern if you allow others to rez objects on your plot.
I would prefer that RAM quota and time slices on objects attached to an avatar (as opposed to rezzed on a plot) be handled as an always-applied, fixed RAM quota and round robin scheduling as I originally described.
This works much better than disabling scripts, which I do not believe Second Life should have ever supported. Most people's avatars break when scripts are off. If you aren't an avatar that needs scripts to animate your body (like a furry or robot), you probably still need to use HUDs.
Avatars pass between plots. People should be able to rely on a certain amount of RAM and processor time for their avatar no matter where they are passing through. Restricting them as I originally described prevents one avatar's use of resources from harming others or their plots.
Remember, even if an avatar is not on your plot, if it is still somewhere in the same sim, it is still using RAM and processor time from the same pool. You could ban them and their objects from your plot but not the sim, unless you own the whole sim. This is as it should be. That is why I treat avatar and plot quotas separately.
With the original design for delegating RAM and this post's design for delegating time slices, plot owners should now be able to prevent any space or time exhaustion attacks on their individual plot even if they allow others to rez objects on them.
Kathrine Jansma
Coaldust Numbers
Good points. The tricky part comes when trying to handle OOM conditions/hitting the quota. Especially multi-script contraptions will not survive if parts of their ensemble are not loaded due to OOM conditions and might not have a way to recover.
So this would only work for new scripts and might introduce additional complexities, if the governor needs to enforce a quota for unequal entities. Like on the server side you might have scripts compiled to Lua from various source representations, e.g. legacy LSL, Mono LSL, Lua. Now your governor can either break existing content with random OOM killing of running scripts (fatal and for eternity for no-mod objects), or not enforce the quota for legacy content.
LL could in theory do some inventory checks to determine safe limits used by legacy content, e.g. count the maxmium number of scripts in any existing content and declare that + 1% or so as new absolute limit. But you could still not elect a legacy script as a safe candidate for OOM kills.
So yes, your design is more secure (classic mobile agent style ressource constraints...), but especially enforcing memory usage limits would be very likely content breaking. No issues with CPU time limits though.
Coaldust Numbers
Kathrine Jansma
I tried to avoid these criticisms.
The OOM condition should be simple enough. If rezzing the object would put the user over the quota, it does not rez. Determining if this would be the case is a simple matter of adding up the memory all scripts inside the object say they require and seeing if subtracting that amount from their remaining quota would go negative. Obviously, nothing bad can happen from an object not rezzing. It is as if you never tried to rez it, other than a notification about why this was forbidden.
My suggestions would work for existing, not just new, scripts. Existing scripts would be considered to require 64KiB. This is how they already work.
How a script was compiled is irrelevant. All methods take space. Enforcing the RAM quota only cares about how much space a script requires, and we know how much space each script requires.
There are no random OOM killings. No overallocation occurs. Indeed, overallocation
must not occur
. That is what we are stopping. An avatar or plot has a certain amount of RAM reserved. It may use less than that, but it will be prevented from ever using more than that.Content breaking should only occur if someone has been being abusive. Quota levels should be set high enough for most avatars and plots to work as is. I am, however, happy to break people's grey goo scripts. That is the goal!
This, like all forms of security that actually work, is all about prevention, not cure. Therefore, we
could
allow currently over-quota avatars and plots to continue as is. But as soon as someone detaches an object from themselves or picks it up from their plot while over-quota, they will not be able to re-rez it. Rezzing more on an over-quota avatar or plot would also be forbidden because the check would occur upon a rez attempt (again, prevention
). This is similar to how megaprims were handled. New ones could not be created, but existing ones persisted. That should cover all
reasonable objections to this plan.Remember, there is already a RAM quota. It is how much RAM is in the sim. Running out will already cause objects to fail to load properly. All I want to change is to keep avatars or plots with way too many scripts on them from taking up RAM and processor time that rightly belongs to others. It is currently unfair and insecure.
Coaldust Numbers
This requires no extra effort when implementing server- and client-side Lua scripting. A security model must be implemented. Code for allocating RAM for Lua scripts must be written. Code for scheduling Lua scripts must be written. This must all be integrated with the code that runs existing LSL scripts. It may as well be done right instead of perpetuating the mistakes of LSL in a new programming language and in client-side scripting. Linden Labs may as well fix the space and time exhaustion attacks in LSL scripting in the process.
This will break no valid content. The space and time a user can consume is already limited by the simulator and what others consumed. This only changes things to be fair, to prevent one user from stealing space and time from another.
This will save Linden Labs money. There is no need to hire moderators for an app store. The hopeless task of detecting malware by examining closed, obfuscated, or subtly intentionally vulnerable source is avoided. There is no risk of lawsuits over discriminating against a programmer or allowing harm to come to a user. It does not require more RAM or faster processors. It may
save
RAM and processor time by reducing the fragmentation caused by programmers using workarounds to effectively get more than 64KiB RAM in a single script.This will make programmers happier. They need not pay for their own moderation. They can now use as much RAM as they want, up to the user's quota, in a single script. That will make writing video games and virtual pets possible in Second Life without the lag imposed by workarounds like 'storage scripts' you can only communicate with about 22 times per second or farming out most logic to a server the programmer must rent and waiting even longer for communication via XML-RPC.
This will make users happier. They need not pay for the programmers' moderation. Nobody has to be harmed before malware is detected. There is no need for a barrage of permission request dialogs every time they try to do something because granting permission is a natural part of specifying what they want to do. Things that used to crash, hang, or severely lag simulators now only harm the perpetrators. They can enjoy video games and virtual pets in Second Life without the pauses that ruin gameplay. The things they bought will no longer break because their logic was needlessly farmed out to a server outside Second Life that the programmer quit paying rent for.