Dear folks,
I fully agree with the assessments made here that ~/.forward and
~/.procmailrc should not be writeable by anyone other than owner. When
sendmail, for instance, finds .forward and :include: files in group writable
directories, these files will be marked as unsafe addresses, and are ignored
for delivery to files or programs (this behavior can be altered via the
"DontBlameSendmail" option, but I digress.)
There are, however, a few snares regarding UNIX that not everyone may be
fully aware of. Let us say a user (not root) has a .forward in his home
directory, like this:
drwx------ 2 someone someone 512 Mar 6 2001 .
-r-------- 1 someone someone 24 Dec 14 01:50 .forward
With a mode of 400 (u=r) this seems pretty safe, uh? Even sendmail regards
this a safe .forward file. But it is really not. :) Since the "someone" user
has write access in his own home directory, he can DELETE this file! UNIX
newbies are often baffled by this. But it is not a bug.
Then why can "someone" delete a file he is only supposed to have read access
to?? Because files are traditionally, even in DOS, regarded as directory
entries. And since the "someone" user has write access to his own home
directory, he can delete the read-only .forward file, even if it belonged to
root! So, "someone" can do:
rm .forward
Followed by:
echo "whatever evil deed" > .forward
chmod 400 .forward
And nobody would be any the wiser. :)
There is, of course, a reason why sendmail considers these .forwards file
safe: because a user, in his own home directory, may naturally change his
..forward file. But when used for a delivery scheme like procmail, those who
set up procmail should be aware that their users' .forward file are
essentially unsafe when installed within their own home dir.
When (only) root sets the "sticky" bit on a directory, users can still have
read and/or write permissions for that directory, but they can only remove
or rename files that they own. The sticky bit on a file tells the operating
system that the file will be executed frequently. Files like this are kept
in swap space even when they aren't being executed.
Does it help then to set the sticky bit on every users' home directory? No.
Because if the effective user ID of the process is the same as that of the
owner ID of the directory (which is, of course, the case for a users' home
directory), they can still delete the file. This is one of the reaons why I
really think it is highly advisable to run procmail as LDA from sendmail (or
other program) directly, instead of using the .forward delivery scheme. On a
machine where this was not possible, I solved the insecurity by assigning a
different location for .forward files within sendmail (O
ForwardPath=/usr/shadow/$u/.forward); essentially, for each /usr/home/user/,
I created a (non-writable) /usr/shadow/user/ directory which had the
..forward file.
Although the security risk may not be all that large, personally I think
that those who install procmail should really be aware of this issue when
they decide how to set up procmail. If not for security reasons, then simply
for reasons of maintenance: if users start to mess with their .forward
files, you will be the one having to clean their mess. :)
- Mark
System Administrator Asarian-host.org
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail