Re: [PATCH] Undo some of the pseudo-security madness

[Samium Gromoff <_deepfire@feelingofgreen.ru>]

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...