So you want me to not be able to read the executable, but instead to be able to run arbitrary code from it, including being able to run almost-identical image from it? Does not compute.
If you really care about security, you should let your users fully take control over command-line processing.
If a clisp binary is going to be run as part of a controlled environment, you don't help legitimate users by putting this backdoor in their executables. And you still don't prevent "malicious" users from going all the way to disabling a REPL. You're just making life harder for everyone.
I think that locked binary that can be unlocked with an external tool is the best option:
* it allows the writing of secure binaries
* it allows legitimate/authorized users to easily unlock the binary and tinker with it.
* it disallows non-legitimate/unauthorized users from gaining escalated privileges.
you aren't listening.
your application will be installed by someone else,
and the SOP is to 'chmod -r' all suid apps,
so, de facto, your "bit switch" approach will not work for the user.
note that my approach is conceptually no different
from the "!" command in, e.g., (net)hack which invoked a user shell
(note that hack runs setgid games).
I'm listening, and I think you got it wrong.
If you're an unprivileged user, and the administrator wants to prevent you from seeing inside the clisp binary, he'll be able to. He'll make the binary read-only, wrap its execution in a script, only allow access through telnet, etc. Your backdoor won't help.
If the administrator is OK with letting the user see the binary, then the bit switch approach allows to do it in a way that doesn't jeopardize either 100% correct functionality or security (which are the same thing, really). But your backdoor approach does create a big security concern -- that can be addressed by wrapping, which works (as above) but ultimately defeats the goal of a standalone executable.
In other words, your backdoor never helps, but only is detrimental, as compared to the bit switch.
with the --clisp-x approach, if you can run the application, you can get the REPL (unless the admin is extra malicious, which I don't this is a realistic expectation, and, given the OSS nature of CLISP, cannot be full forestalled anyway) - safely, because --clisp-* ==> unsuid.
with the bit flip approach, you need to be able to read the executable, which is unlikely in case of a suid application because of a SOP.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.