I would instead suggest running the program in a sandboxed environment to see what it does, and if it appears to be malicious, (re)move it.

Anti-viruses are also a lot less useful since 1.76 simply because you can protect yourself against them now if you have a secure system.

Somehow I got it to work... I guess unloading the APIs really is a bad idea.

The only API I had to reload was the IO API.
I have no idea how I got the others to work.

Here's the method I used (worked)

local sandbox = {--[[ Generate environment here ]]}    -- Your sandbox environment
sandbox._G = sandbox
sandbox.func = function(...)	 -- Do this for each function
  _ENV = sandbox
  return func(...)
end

Thanks for your help.

Bomb Bloke, on 17 January 2016 - 12:34 AM, said:

There's a problem with that. I want to unload all the APIs bios.lua initialized and I want to reload those in the sandboxed filesystem.
I've already sandboxed os.loadAPI to load APIs into the sandboxed environment.

ZippoMoon, on 16 January 2016 - 11:54 PM, said:

You need to add tostring if it's not a string otherwise you'll get an error about concatenating string and insert type here

Bomb Bloke, on 16 January 2016 - 11:44 PM, said:

I'm enclosing each function in a function whose _ENV is equal to the sandbox. Kind of like this:

sandbox[function] = function(...)
  _ENV = sandbox
  return _G[function](...)
end

However, APIs that define variables outside the function definition can no longer access those variables. And they do use the sandbox environment, functions inherit their environment from the function above them in the stack.

It returns a table, so just get the index in the table.

local atable = {
  ["key"] = "Value"
}
print(atable.key)    -- Prints "Value"
print(atable["key"])    -- Prints "Value"

The latter is more useful when Lua could misinterpret the dot notation (spaces or special characters in key). It is also more useful when you're dynamically indexing the table.

I'd like to sandbox all functions by embedding each of them inside a function where _ENV is set to the sandbox table.

Unfortunately, APIs often declare variables outside the function, which get excluded by my idea of using _ENV (and setfenv wouldn't help either).
My plan to work around this is to unload all APIs and reload them in the sandbox table.

Unfortunately, if I try to reload all of them (except term, window and those the computer can't access), the computer just shuts down.

How would I reload all the available APIs without the computer shutting down?

Lua doesn't use regular expressions, it uses patterns.

HPWebcamAble, on 15 January 2016 - 01:13 AM, said:

Ideally, rednet shouldn't even be used (easy packet sniffing and predictably simple protocol).

Be careful because it is possible to write a virus that infects disks (I've done it before for demonstrational purposes).

To avoid this, you'll want to shutdown (Ctrl + S), insert the disk, and start the computer.
Otherwise, some viruses might infect the disk.

Lupus590, on 14 January 2016 - 06:23 PM, said:

Thank you Lupus but I already know what each one does. I've solved the problem by assigning all the global variables I want to pass down to a key in a table, which I then pass in to os.run/

Bomb Bloke, on 14 January 2016 - 12:29 AM, said:

I've tried passing it an empty table, but that doesn't work, they don't have access to global environment variables previously set in the same program (and that's also a relief for sandboxing).

When calling os.run with the global table, I get a "loop in gettable" error.

How would I use it with the global table?

Thank you for finally adding an option for disabling disk startup!

Unfortunately, that doesn't allow the individual modification of each computer's rom.

Ah, well at least a way of modifying all rom files (except bios.lua) then.

While it is possible to, in some way, modify the ROM by screwing with the fs / io API, I would like to change rom/startup because it can cause security exploits (most notably with disks) and modifying the API just doesn't make the cut because rom/startup is already run before /startup. I would also like it to be possible to have each computer have a custom rom, to allow for it on servers.

Would it be possible to allow the person who placed the computer to modify the rom directory or allow its modification only when a new computer is placed (computer must be backed up and replaced to fix)?

This system could become 100% secure simply by requiring that the person labels their computer and the OS checks the computer's ID every startup to verify that a potential hacker hasn't (somehow) copied all files off and replaced the computer with a new one. On top of that, the hacker wouldn't even be able to obtain the files without breaking into the OS, assuming the OS is custom and supports user-level security (or file encryption).

Here's how exactly it could work...

• User places a new computer (new ID generated)
  
  
  
  
• Computer asks the user if they want to modify the rom (recommends to select "no")
  
  
  
  
• If yes, computer opens up into a basic shell where the user is asked to select a disk drive containing the new rom
  
  
  
  
• Computer then resumes running by going through the OS's security checks (OS handles sandboxing, etc).
  
  
  
  
• User now has a secure computer.

I don't see how this could be misused and hope that it gets implemented.