At 13:00 2005-05-13 -0400, D E Hammond wrote:
[quoting something I previously wrote:]
> You might consider just putting the procmail.config in the
> /etc/procmailrcs/ dir, since that's a directory already associated with
> procmail - no, it won't auto-load from there, but it'll keep your procmail
> related stuff in a procmail related place.
Philip Guenther once warned against using /etc/procmailrcs because not
only is it associated with procmail but it has a special meaning that
he suggested might open security holes if used in a way other than its
intended purpose.
When invoked, procmail runs /etc/procmailrcs/ (and any subdirs from there
have the same qualities) rcfiles as the user who owns the file in that
directory. if you have an includerc'd file there, procmail will already
have been running another rcfile (say, the users own procmailrc that
included the "variables" file), and would be running at the appropriate
privledge level associated with that invocation. If the variables file
merely defines variables (x=123), and doesn't invoke programs to do so,
then there would be absolutely no risk to invoking it.
However, if the variables file invokes programs - esp from arguments, then
yes, it could be a potential security risk if it had just the right set of
operations and someone were to invoke it with the proper arguments. One
might expect that starting it with a DROPRIVS=YES would make short work of
that, but if the STARTING rcfile is in /etc/procmailrcs/ then that's the
UID that procmail believes it is running for, not the UID of the user who
invoked the program (properly installed, procmail is SUID root). However,
setting its owner to a nonprivledged user ('nobody' for instance) would cut
it off at the knees.
As an experiment, as root, create the following file:
/etc/procmailrcs/whoami.rc
and in it, put:
:0
LOG=|whoami
Now, as a regular user, invoke:
echo | procmail -m /etc/procmailrcs/whoami.rc
and you'll see 'root' gets echoed out to the console, which is expected.
If you put DROPPRIVS=YES at the top of that rcfile and re-run the user
command above, it'll STILL output 'root' to the console. For some users
familiar with /etc/procmailrc (a file, not the /etc/procmailrcs/
directory), this apparent "FAILURE" of the DROPPRIVS directive might be a
surprise.
Now, remove DROPPRIVS=YES from the file and change the owner to
nobody. Re-invoke as a user, and you'll likely find that procmail
complains about an inability to chdir or execute the binary file (for lack
of a useable homedirectory and shell for the nobody user). To successfully
run as nobody, you'd need to define a shell and likely a path as well (or
hardcode paths to things you attempt to invoke). Then, the rcfile, if
invoked directly, would be run as user nobody.
As a regular user, create an rcfile in your own home dir and put the
following into it:
INCLUDERC=/etc/procmailrcs/whoami.rc
and invoke it:
echo | procmail -m some_rcfile.rc
Your own uid will be shown, because procmail was running as the user BEFORE
it processed the INCLUDERC.
However, you're entirely right - unless you're paying attention to what
you're doing, placing files into the /etc/procmailrc which have not been
sufficiently vetted for security can indeed be a problem, and I retract my
advice to "just move the settings file there", esp since I didn't elaborate
on the conditions. The user to whom I gave that advise was also obviously
new to procmail (not being familiar with INCLUDERC), so one could expect
that there may have been a snafu as a result if the file were to contain
other commands and be invoked directly rather than as an INCLUDERC.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail