procmail
[Top] [All Lists]

Re: permissions on .procmailrc file

2001-06-11 10:40:43
What is the GROUP_PER_USER definition for then?
Wouldnt this fix all of my problems?  If I have a cgi group and the .procmailrc
is set to 664
then everyone in that cgi group should be able to write to that file and
procmail wont have a problem
with it being 664.  given that the cgi group owns the file.

I have another email in the loop that talks a bit about this.

Philip Guenther wrote:

Terry Davis <tdavis(_at_)birddog(_dot_)com> writes:
I am writing a cgi that will allow editing of a .procmailrc file.

This script runs as nobody.  If I change the perms of the .procmailrc file
to anything but 644 procmail seems to ignore it.
I can have the script run as root but that would be bad.  But at that point
I can do whatever with the file perms on the file at that point.

First of all, it's generally a bad idea to use the "nobody" user as the
user that CGI programs are run under.  The "nobody" has a particular
meaning related to NFS that it is given by the kernel and it should not
be used for other purposes, especially things like CGI which may need
and deserve access to particular directories and files.  I *strongly*
suggest that you create a "cgi" user and run them as that user by default.
It won't solve this problem, but it'll prevent security and management
problems in the future.  I'll assume for the rest of this that you've
done that.

So, there are a couple options:
1) make procmail trust rcfiles owned by "cgi", or
2) create a setuid root helper program that's invoked by the CGI program
   to give a user's rcfile the correct ownership and permissions, or
3) make the CGI program itself setuid root and have it set the correct
   ownership and permissions directly.

I argue that option three is the most secure of these option.  Why?
The short answer is that you need a strong chain of authentication
and authorization at each step from user to webpage, to CGI program,
to rcfile, to procmail.  In particular...

Under option one, if someone untrusted obtains user "cgi" privileges
(there's a security hole in one of the other CGI programs) then they
can forge rcfiles.  It's fairly easy to lever that ability into root
privileges by manipulating the .procmailrc files of users who can su
to root.

Option two suffers from the setuid helper program's inability to
authenticate the invoking CGI program as the one that is authorised to
change rcfiles.  And no, puting a 'secret' into the correct CGI program
won't help because other processes running as user cgi can read the
secret from its memory.

Look at it this way: that CGI program, by dint of its ability to change
users' rcfiles, is effectively trusted with root privileges and any holes
in it can be used to obtain root privileges.  Given that, running it
as root directly is *more* secure, because otherwise you've just turned
that other uid into another name for "root".

Philip Guenther
Procmail Maintainer
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

<Prev in Thread] Current Thread [Next in Thread>