>>>>> "S" == SRE <eckert@climber.org> writes:
S> I need some help finding several parts of the install code, because not
S> all the permissions seem to be set properly and the setuid wrappers are
S> open to exploits involving environment variables (e.g. LD_LIBRARY_PATH)
S> according to my sysadmin. The exploit stuff is way down below...
The setuid wrappers we use are the ones the Perl authors suggest. setuid
shell scripts may be insecure, but that's why we have the wrappers.
S> Logged in as anyone else, except root, the shell cannot be started:
S> /home/mj2/bin/mj_shell: Permission denied
Yep. As expected.
S> FIRST PROBLEM: The install procedure happily writes to a directory that
S> no one else, including the sendmail daemon, can read.
Yep. This is as expected. You can't really expect it to work otherwise.
S> SECOND PROBLEM? A couple of entries in the bin directory are not
S> wrappers? Are mj_queuerun and mj_queueserv so safe they don't need
S> wrappers, or is this just an oversight?
Only programs which must be run by users or by the MTA (depending on the
MTA) need to be setuid. Those programs are neither, thus there is no
reason for them to be setuid. The same goes for mj_trigger, since it is to
be run from the Majordomo user's crontab.
S> THIRD PROBLEM: I didn't find the compile command line, but I don't think
S> the binary is stripped or that there is any checking of the environment
S> variables.
There shouldn't be, really. LD_LIBRARY_PATH, if your system was stupid
enough to actually pay attention to it for setuid executables, would have
already come into play. And the rest of the environment is tainted by
Perl. (And any special environment variables which Perl might pay
attention to are ignored because Perl is being run from a setuid program.)
S> Can anyone comment on safe environments for Mj2?
It's not just Mj2. We are following the advice explicitly given to us by
the Perl developers. If Mj2 is insecure _because of those methods_ (not
because of any boneheaded coding errors that we made elsewhere) then the
problem is very large indeed, because the method in use is the accepted one
according to people who know lots more about security then I do.
S> FOURTH PROBLEM: Really a question: Since I finished the install NOT EVER
S> BEING ROOT, and since the wrappers supposedly do a setuid, does this
S> mean that using "su" to become the server process ID is safer than using
S> "su" to become root for the installation?
More likely you're just not able to do the appropriate chmod and your stuff
really isn't setuid.
The bottom line: no offense to SRE, but I don't believe you're qualified to
do a security audit. I'm not really either, but in any case, the method
you're critiquing was given to me by folks like Larry Wall (I asked
explicitly if the suggested stuff has stood up to thorough review), so if
you're going to say that it is fundamentally flawed, then I'd like more
concrete explanations of the involved exploits. Anything else really is
FUD.
For further reading, I suggest the "perlsec" manpage. Here's a relevant
portion:
However, if the kernel set-id script feature isn't disabled, Perl will
complain loudly that your set-id script is insecure. You'll need to either
disable the kernel set-id script feature, or put a C wrapper around the
script. A C wrapper is just a compiled program that does nothing except
call your Perl program. Compiled programs are not subject to the kernel
bug that plagues set-id scripts. Here's a simple wrapper, written in C:
#define REAL_PATH "/path/to/script"
main(ac, av)
char **av;
{
execv(REAL_PATH, av);
}
Compile this wrapper into a binary executable and then make it rather than
your script setuid or setgid.
See the program wrapsuid in the eg directory of your Perl distribution for a
convenient way to do this automatically for all your setuid Perl programs.
It moves setuid scripts into files with the same name plus a leading dot,
and then compiles a wrapper like the one above for each of them.
Note how our behavior follows _exactly_ that described here.
- J<
Follow-Ups:
References:
|
|
