procmail
[Top] [All Lists]

Re: Preventing execution of arbitrary programs

1997-05-13 11:33:00
Eric Daniel wrote:

D> At the same time, it would be nice to allow procmail, but then, of course,
D> the pipe action kind of defeats the purpose of smrsh.

One thing about procmail is that, as soon as it reads an rcfile other than
/etc/procmailrc [or something under the /etc/procmailrcs/ directory with no
backreferences (no "/../" to sneak out of the tree)], it gives up its setuid
privileges and changes uid to that of the owner of the rcfile.  So a pipe
action in a user's .procmailrc will be executed under the user's uid without
root powers.  Therefore there is no need to disable pipe actions in rcfiles.
[I've no experience with procmail as the MDA, so PLEASE correct me if I'm
wrong about that.]

Tim Wynn has already responded to Eric,

W> After looking things over, the only point of concern that I have found
W> security-wise with procmail is with /etc/procmailrc.  From the
W> documentation, it appears that anything run through the global
W> /etc/procmailrc runs as root, at least briefly (if procmail is run
W> setuid root, as recommended).

Setting 

  DROPPRIVS = on

in /etc/procmailrc will make procmail give up setuid and setgid privileges
immediately and read the rest of /etc/procmailrc under the id and group of
the recipient.  As long as procmail doesn't need to do things like creating
$ORGMAIL in a directory with limited write permissions, you can probably
put that assignment at the very top of /etc/procmailrc and get rid of the
privileges right then.

| I'd hate to have to constantly check that
| somebody hasn't created a rogue /etc/procmailrc file that defeats the
| smrsh restrictions I have put in place.

"/etc/procmailrc" is an absolute path; it doesn't mean ~user/etc/procmailrc
for each user.  So unless the /etc directory is world-writable or your root
login has been kracked (in which case nothing is safe), no one can create a
rogue /etc/procmailrc.