S> Logged in as anyone else, except root, the shell cannot be started:
S> /home/mj2/bin/mj_shell: Permission denied
At 05:14 PM 8/26/00, Jason L Tibbitts III wrote:
>Yep. As expected.
What may have been lost in my post was that once the directory
permissions are fixed, ANYONE can run mj_shell. The permission
denied was NOT a setuid problem or a safety kicking in, it was an
inability to read the directory containing the Mj2 "bin" directory.
>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.
Really? There's code which purports to check for proper readability,
but it doesn't work. I'm not sure HOW to check, but we ought to at
least warn the installer that (every, or just one?) directory above
the target directory must have a "chmod" done on it, and that our
install procedure won't guarantee a running mail server without it.
>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.)
I'm not sure I understand that, but I guess I'll believe that you've
looked into it and we're all OK. If I'm close to understanding, you're
saying that any setuid program receives special treatment from the
operating system, and the environment is ignored for the life of that
setuid program? That surprises me, but it certainly could be true.
>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.
Got it.
>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.
Have a look at the "ls -l" I sent. It is INDEED setuid, and I was never root.
The secret seems to be that it's "setuid mj2", not "setuid root", and since
I was logged in as user "mj2" it all worked.
>The bottom line: no offense to SRE, but I don't believe you're qualified to
>do a security audit.
I'm not! I'm passing on concerns from my sysadmin. I stated my ignorance
up front, and don't want you to interpret any of this as an attack. Even
my subject line is a question, because I'm just not sure about it... so
when I'm unsure, I tend to ask a lot of questions.
Would it be better to tell installers to switch to the userid under which
the server will run while installing, instead of telling them to be root?
I can think of several HUGE benefits of this: First, my sysadmin will
never let me be root but he's OK with me being "the server process" for
a while (because that user has no ability to read/write outside its file
space, unlike root). Second, an errant install procedure can't do as much
damage when the user running it isn't root (even if you know what you're
doing and you own the system, it's better to do things as the least
privileged user which can get the job done).
Note that this would be a doc change only, no change to the software itself.
I'm asking if we should prominently point out that you DO NOT need to be root.
SRE
mailto:eckert@climber.org | http://www.climber.org/eckert/
Info on peak climbing email lists mailto:info@climber.org
"A free society is one where it is safe to be unpopular."
-- Adlai Stevenson
References:
|
|
