  |
GoFiler Legato Script Reference
Legato v 1.5b Application v 5.24b
|
| Table of Contents | < < Previous | Next >> |
Chapter Two — Language Overview (continued)
By default, Legato 1.x runs in a wide-open fashion with all functions able to access the local system at the security level designated by Windows user account settings and group policy settings. Certain applications may require scripts to be digitally signed before they will run or certain authors may wish to obfuscate or crunch their code.
Code signing operates in a manner similar to that of Java and other languages in that a certificate from a trusted third-party is employed to add a signature to a file.
Code crunching is a method of compiling or preprocessing a script and then encrypting it so it is difficult for third parties to directly read the code. The code can still be executed by a script engine but it is no longer in a human readable form.
All functions are presently open. Certain functions are always checked by the operating system such as file and internet access.
A minor security risk exists in all programs in that if an invasive foreign software can get access to program memory, it might be able to glean user names, passwords and other sensitive information. Generally, if a system has been penetrated to that level, the owner may well have many more problems than worrying about security within Legato.
Throughout the script engine, steps have been taken to reduce the chances of a memory observer spying on data left over from program operations. For example, when a string must be reallocated or repositioned in memory, the old position is cleared in its entirety, even of sections of the memory were not used. This is part of what is reference to in Legato as a Secure Memory Model.
Certain sensitive functions will clear any working data from the internal stack area (local variables) after completion. For example, IsUserInGroup allows for optional user name and password, these are cleared on function exit. Functions that have specific provisions for clearing memory will note such in their respective documentation.
The function SecureClear allows a variable to be completely cleared and also clears the internal script engine working string pool. By default, the working string pool is not cleared on every operation owing to processing overhead.
No matter what, as sensitive data processed, it will be in memory until the variable is cleared or released. Best practice is to SecureClear global variables when they are no longer needed. Local variables are cleared when a function exits.
On function exit, local variables are not cleared unless the service variable pool manager is reused or SecureClear is called prior to exit.
When a script terminates, all of its resources are cleared.
See also Handling Password as part of the Microsoft Developer Network for more information.
| Table of Contents | < < Previous | Next >> |
© 2012-2024 Novaworks, LLC. All rights reserved worldwide. Unauthorized use, duplication or transmission prohibited by law. Portions of the software are protected by US Patents 10,095,672, 10,706,221 and 11,210,456. GoFiler™ and Legato™ are trademarks of Novaworks, LLC. EDGAR® is a federally registered trademark of the U.S. Securities and Exchange Commission. Novaworks is not affiliated with or approved by the U.S. Securities and Exchange Commission. All other trademarks are property of their respective owners. Use of the features specified in this language are subject to terms, conditions and limitations of the Software License Agreement.