• SeerLite
    link
    fedilink
    33 years ago

    Running everything sandboxed even if the software that’s being run is FOSS and comes from trusted sources doesn’t sound too bad though. Just another layer of defense. What are the potential security issues this could cause?

    • poVoq
      link
      fedilink
      1
      edit-2
      3 years ago

      No, but what would be the benefit? Sandboxed are only needed when running untrusted code. That is unavoidable sometimes as the web would be pretty much unusable without javascript. But when someone tries to sell you a sandbox the malware distribution channel usually follows closely behind (I am looking at you Snapstore >:( ).

      • @pinknoise@lemmy.ml
        link
        fedilink
        2
        edit-2
        3 years ago

        Just a bunch of stupid bugs can turn your well behaved code into malware. You should not trust any code to do what you think it does, especially if you have written it yourself. If it’s possible to enforce fine grained access control and isolation then it should be done.

        the web would be pretty much unusable without javascript.

        Imo it would be a better place without it

        • poVoq
          link
          fedilink
          13 years ago

          A bug is not malware (i.e. software intentionally written to do harm). It might get exploited, but that is an entirely different story and usually requires another piece of actual malware to work.

          Adding a sandbox to mitigate against bugs might sound like a good idea at first, but in reality it adds bloat and makes people stop actually fixing bugs. And a lot of the impacts of bugs can be more easily mitigated against with general system improvements that actually make the system overall better instead of adding layers of bloat. Take Rust for example: it is a memory safe language that actually improves the system, but of course a sandbox can also mitigate against software written in memory unsafe languages. But hopefully you agree that Rust is the better idea then wrapping everything in a sandbox.

          As for Javascript on the web. No it would be a much poorer system overall, with people reverting to shoddy apps to supplement webcontent. Maybe you are having rose tinted glasses or are too young to remember, but the web was not better before widespread javascript use. In fact it had stuff like Shockwave and Flash to do some of what Javascript does today shudder

          • @pinknoise@lemmy.ml
            link
            fedilink
            2
            edit-2
            3 years ago

            And a lot of the impacts of bugs can be more easily mitigated against with general system improvements

            Yes and these improvements will converge to be a sandboxed environment. Even original unix had (weak) process isolation and ACL’s. Should we go back to cooperative multitasking because a scheduler is bloat? No, because it’s not practical. Should we remove all exploit mitigations and fix all the bugs instead? No, because it’s not practical. For reasonably complex programs we can’t tell if they are bug-free and even if we could the hardware it runs on may have bugs. The best we can do is minimize the impact a glitched program can realistically have.

            Rust is the better idea then wrapping everything in a sandbox.

            Rust prevents a range of stupid bugs that don’t have to happen. (plus other cool stuff) It can’t prevent logic bugs. Say e.g. you have a server with an unintentional arbitrary file inclusion. Would you rather like to wait for the bug to be fixed and be completely vulnerable in the meantime or have the impact limited to the files the server process/user is explicitely allowed to access?

            In fact it had stuff like Shockwave and Flash

            Sure, compared to those (whose turing completeness javascript predates btw.) it’s nice but no builtin RCE at all is still the better solution.