Procmail Sanitizer 2.0 policy files $Id: sanitizer.txt,v 1.16 2002-10-10 18:56:25-07 jhardin Exp jhardin $ (c) 2002 John Hardin Copying permitted under the GNU Free Documentation license available at http://www.gnu.org/copyleft/fdl.html Available online at: http://www.impsec.org/email-tools/development/sanitizer/sanitizer.txt This is a work-in-progress. Comments are solicited. --------------------------------------------------------------------- There are four possible things to do to an attached file: Allow it to pass unchanged; Mangle the filename; Strip it off the message and quarantine it; Strip it off the message and discard it. An attachment can also have the following side effects: Poison and quarantine the message; Poison and discard the message. These six possibilities are the "primary policies". There are other actions that can happen as well: Log the filename Notify the administrator (i.e. $SECURITY_NOTIFY) Notify the recipient Notify the sender Scan for viruses (or, generically, pipe the attachment through an external program) Reformat (e.g. delete spammers' embedded HTML comments) (any others?) Policy Codes: A (Accept) M (Mangle) S & SQ (Strip & Quarantine) SD (Strip & Discard) P & PQ (Poison & Quarantine) PD (Poison & Discard) L (Log filename) N (Notify administrator) F (Notify From: (the sender)) T (Notify To: if message poisoned) V (Scan for viruses - Real Soon Now... :) O (Scan for suspect MS Office VBA/macros[1]) Syntax: fileglob handling[:comment_filename[:comment_filename...]] [notify_filename[:notify filename...]] Example: *.vb[a-z] PDLNF:/etc/procmail/comment-vbs.txt *.dll SD *.exe M *.doc AF /etc/procmail/please-use-rtf.txt The sanitizer will allow combinations of primary policies, and if they are in conflict will choose the most restrictive possibility to ensure security. For example, APD and MPD would both result in the message being discarded, as "D" has precedence. The 1.x sanitizer's behavior is MPQ for attachments in the poisoned list, SD for attachments in the strip list, M for attachments in the MANGLE list, and A for the rest. Sanitizer glob+RE syntax is still used. Note that this breaks certain standard RE constructs; most notably there is no way to use * to indicate zero-or-more repetition and no way to use ? to indicate optional, as "*" gets translated into ".*" and "?" gets translated into ".". Filename globs are not case-sensitive. I'm also strongly considering supporting MIME type matching, so that you could do something like: text/html PDF /etc/procmail/html-mail-not-wanted-here.txt The comment-filename(s) will be read into the log attachment generated when message processing is complete, so you can say, for example, "Visual Basic script attachment removed per local security policy" or some such. There will be some printf-style substitutions supported for the text in the file, for example %f -> attachment filename, %q -> quarantine filename, etc. The notify-filename(s) will be appended to the default sender- and recipient-notify file the handling specifies to notify. This part needs refinement, as I want to be able to use this to notify the sender about things such as "HTML not wanted" and "Word documents not wanted" without firing off the default "may be infected" type message. Maybe something like, you need to include "::" to include the default message. I'd also like to be able to specify different messages for the FROM and TO notifications; maybe look in subdirs for the file first. Standard #-begins-comment syntax is supported in the policy file. The hashmark MUST be preceded by whitespace or appear at the beginning of the line. Multiple policy files may be specified and all will be concatenated; the first policy that matches the filename in question will be used: SECURITY_POLICY_DIR="/var/opt/sanitizer/policies" SECURITY_POLICY="accept-docs.san:poison-known-attacks.san:mangle-executables.san:default-accept.san" As a speed enhancement, the sanitizer may perform some "compiling" of policy files - e.g. pre-strip comments and write them out in a quickly-loadable format. I would also like to put in C-style preprocessor #ifdefs, so that if you don't want the macro scanning code (or other features), stripping it out of the perl script will be easy. This would save the overhead of compiling unused code on every message. SECURITY_RFC822_MAXLEN specifies a file containing the maximum allowable length for RFC822 headers on a by-header basis. For example, the built-in defaults would be coded by: Date: 250 From: 250 Status: 250 Subject: 250 X-Status: 250 X-Keywords: 250 Message-ID: 250 Resent-Date: 250 MIME-Version: 250 Case is ignored. The minimum length is 32, but there probably won't be any situation where you need to set a length limit that short. If a buffer-overflow exploit of a particular header is announced (e.g. the Outlook Express overflow in the Subject header at about 255 bytes), set the length limit to slightly less than the length of the exploit. Headers exceeding this length will be truncated. Headers not listed will not be length-limited. You should not length-limit Received: headers. New security configuration variables: SECURITY_POLICY_DIR SECURITY_POLICY SECURITY_QUARANTINE_DIR SECURITY_FILENAME_LOG SECURITY_DECODE_TEXT SECURITY_DISABLE_MACRO_SCAN SECURITY_RFC822_MAXLEN New program configuration variables: CHARSET MAX_BP_SZ TMPDIR Deprecated configuration variables: MANGLE_EXTENSIONS DISABLE_MACRO_CHECK Required external code: From CPAN: File::MkTemp MIME::Base64 MIME::QuotedPrint Locale::PGetText Convert::TNEF Deprecated external code: mimencode mktemp The perl script policy-check.pl is the policy handling parts of the sanitizer. You can use it to develop and test your policies. To test a policy: export DEBUG=1 # or, alternatively: export DEBUG_VERBOSE=1 export SECURITY_POLICY_DIR=`pwd` # or wherever the relative policy files reside export SECURITY_POLICY="file1:file2:/dir/dir/file3:etc" export SECURITY_QUARANTINE_DIR="/tmp" # just to keep the script happy perl policy-check.pl filename filename filename ... Encoded filenames such as =?iso-8859-1?Q?=F6sterreich.jpg=2E=56=42=53?= should be handled properly, but include them in 'single quotes' for testing so that the shell's filename globbing does not mangle them. Proper support for encoded filenames will mean that the filename mangling will change slightly from earlier versions of the sanitizer. Notes: [1] Do not use this in your policies; the sanitizer will automatically supply it when appropriate. EOF