Messages in this thread | | | Date | Mon, 22 Jan 2007 03:54:03 +0300 | From | Samium Gromoff <> | Subject | Re: [PATCH] Undo some of the pseudo-security madness |
| |
David Wagner wrote: > Samium Gromoff wrote: > >[...] directly setuid root the lisp system executable itself [...] > > Like I said, that sounds like a bad idea to me. Sounds like a recipe for > privilege escalation vulnerabilities. Was the lisp system executable > really implemented to be secure even when you make it setuid root? > Setting the setuid-root bit on programs that didn't expect to be > setuid-root is generally not a very safe thing to do. [1]
1. Unsafe setuid programs have been written, and they doubtlessly will continue to be written.
2. Lisp systems are written by extremely competent people. (who make mistakes nonetheless, but still..)
3. I think that the ability to choose whether or not to shoot oneself in the foot is an important freedom.
4. The whole issue is a little bit unfair, because the UNIX world is inherently C-centric -- everything outside the C niche does not, indeed, fit flawlessly in the picture.. This is where the "if you want to write system software, do it in C" model comes from.
5. If a killer use-case is needed, an X server might do -- these need root privileges for a certain period.
What if i decide that i want to write one in Lisp?
> The more I hear, the more unconvinced I am by this use case. > > If you don't care about the security issues created by (mis)using the lisp > interpreter in this way, then like I suggested before, you can always ^^^^^^^^^^^ make that a compiler -- these days, probably, there are more native-bytecode-generating lisp compilers than interpreters.
> write a tiny setuid-root wrapper program that turns off address space > randomization and exec()s the lisp system executable, and leave the lisp > system executable non-setuid and don't touch the code in the Linux kernel. > That strikes me as a better solution: those who don't mind the security > risks can take all the risks they want, without forcing others to take > unwanted and unnecessary risks.
This might sound as a reasonable solution.
Although it places a certain burden, which has to be considered...
I should see what the SBCL people will say about that.
> It's not that I'm wedded to address space randomization of setuid > programs, or that I think it would be a disaster if this patch were > accepted. Local privilege escalation attacks aren't the end of the world; > in all honesty, they're pretty much irrelevant to many or most users. > It's just that the arguments I'm hearing advanced in support of this > change seem dubious, and the change does eliminate one of the defenses > against a certain (narrow) class of attacks. > > > [1] In comparison, suidperl was designed to be installed setuid-root, > and it takes special precautions to be safe in this usage. (And even it > has had some security vulnerabilities, despite its best efforts, which > illustrates how tricky this business can be.) Setting the setuid-root > bit on a large complex interpreter that wasn't designed to be setuid-root > seems like a pretty dubious proposition to me.
Compiler, not interpreter, careful with the insults :-)
regards, Samium Gromoff
P.S. please cc me, as i am not subscribed to the list... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |