Solved Security of new .cs plugins

Discussion in 'Rust Discussion' started by XperienC, Feb 10, 2015.

  1. Hatemail

    Hatemail

    We've sandbox file access to the local oxide directory so that plugins can't maliciously do anything outside of that directory. We have sandboxed known namespaces that could potentially be used for malicious intent. There is always a possibility that we have missed something just like any piece of software. Sever providers should also be running customer instances in their own sandbox usually a vm.
     
    Hatemail, Feb 13, 2015
    #21
  2. Sir Eb

    Sir Eb

    @Hatemail, most gsp use "TCAdmin" as Interface, if the description of "run as TCAGame" is right, then it creates a "Sandbox" for the server itself. So a lua bug would only harm the bugusers own folder.
    [DOUBLEPOST=1423849059][/DOUBLEPOST]
    already tested virtual machines for the new rust, but the new rust doesn't seem to like tcadmin, so it says "Nope no graphics device found ... crash !!"
     
    Sir Eb, Feb 13, 2015
    #22
  3. MrStatoil

    MrStatoil

    Latest message from Multiplay / ClanForge for others that might rent a server there.
    I don't know exactly how this plugins are coded and what filetypes people are using in there plugins, but if the security issue is cause of .cs - Please stop code with .cs files so anybody (no matter server provider) can use the plugins. And yeah, all I know is that plugin developers have mostly been coding in .lua and .json files.
     
    MrStatoil, Feb 28, 2015
    #23
  4. Wulf

    Wulf Community Admin

    It's not a security issue. CSharp plugins are just as secure as Lua plugins are. Multiplay hasn't given us any evidence of it otherwise, only assumptions on their part with no evidence provided. If you read the previous posts in this thread, you'll see that Lua wasn't that secure up until recently when all the sandboxes were implemented. Any language could be susceptible, but there are currently no known security holes with any of the plugin languages.

    My recommendation would be to switch hosts if you want to use any .cs plugins. It's up to plugin authors what language they want to write their plugins in, but you'd need a host that isn't outright blocking them for no sensible reason. Their concerns are understandable, but misdirected. You could always request an alternative plugin in another language, but I doubt you'll see any plugin authors downgrading from C# to one of the other languages.

    Also, the .json files are purely for configurations, which all plugin languages utilize. You can't code a plugin in .json. The languages that Oxide supports are Lua (.lua), JavaScript (.js), Python (.py), and C#/CSharp (.cs).

    Honestly, the only actual reasons I could see would be that Multiplay either doesn't want to install .NET (which isn't even needed in the latest snapshots), or they are worried about resources. They were supposed to have conducted an "audit" of the source and sandboxing system in Oxide, but they haven't given us anything that would indicate any sort of security risk. As we've mentioned before, we're more than willing to fix any potential security holes if they give us any.
     
    Wulf, Feb 28, 2015
    #24