This is on-topic because security issue are always on topic...
At 07:54 AM 10/01/01 -0700, SRE wrote:
>At 02:31 PM 9/28/01, Bill Moseley wrote:
>>Can you get a new sysadmin? ;)
>I've got a good enough deal to put up with the quirks!
>>You mean the sysadmin allows people with
>>write access to run programs, but they want the programs to not allow write
>>access? How does that provide any security?
>"Can't be hacked." If the program cannot ever open a file for writing,
>then holes in the wrapper script or the program itself cannot result
>in files on the server being altered.
I don't follow. What do you mean by "wrapper" script? A CGI script?
Let's say swish-e has had all the open-for-write calls removed.
Now, you have a CGI script that does:
my $query = $cgi->param('query');
open FH, "$swish-e -w $query|" or die;
Now the entire world has write access to your machine, and not just to
write files (which they might have been able to do if the open calls were
not removed) but can now also execute programs on your machine.
>He's not worried about me, he's
>worried about people hacking the tools I install. You can tell him
>"there's a mode that chooses not to write", and his answer will be
>"there's a hack which can change the mode".
Sure there's a hack. If swish won't write, then don't use swish, use a
"hack" like vi, or pico, or rm, or whatever.
>You can't prove him
>wrong, but you can make a tool which cannot be hacked by simply
>removing all the "open" calls which write files.
If he thinks that way, then it also possible to rename swish to swish-safe
and convince him it's now safe (even though it's the same program).
If swish has open calls in write mode, the program can write, true. Yes,
it can write the index file -- like it's designed to. So if you prevent
people from passing switches that make it write the index, then you have
solved that problem. Those are the open calls that write in swish.
The bigger issue, and the real issue, and the common hack, is buffer
overflows. Someone passes a huge query string which bypasses any checks in
your CGI wrapper, and exploits a programming error and manages to get
arbitrary code to execute. Or if someone sees a place in the code where
user data is passed through a popen call through the shell, then there's
another exploit. I'm sure there's many more.
But, the bottom line, which your sysadmin seems to miss, is that security
is provided by the OS. Swish-e doesn't have to be run a root (as some
servers do), so there's no reason the user that runs swish (and hence
swish) should have any permissions to do anything damaging. That's why
webservers commonly run as user nobody.
[But, even without root access, and *with* the poor CGI scripting shown
above, most good hackers will get root access.]
I know we have discussed this before, and perhaps I'm missing something.
But, security is a touchy issue, and frankly, I'm a bit uncomfortable using
the word "security" with swish-search. In the INSTALL docs I wrote:
swish-search executable. This is a version
of swish-e that cannot write to the index
file. This version may provide somewhat
improved security in a CGI environment.
Which I worry is misleading -- basically because someone that's writing a
CGI application might not take all the standard CGI security precautions
(and might use the above bad perl code, which is commonly done).
If I'm misunderstanding some key point, please detail it. But I just don't
see how removing open-for-write calls adds any security. Do you remove the
open-for-write calls in your HTTP, DNS, and mail servers that write log files?
Received on Mon Oct 1 19:12:16 2001