Sentrion Overview Sentrion Platform Sentrion REAC Sentrion Mimecast Hard Appliances Virtual Appliances
Overview Policy Compliance Secure Content Filtering Cloud Partner Enterprise Community
Overview Download Security Support News Documentation Tips & Tricks DKIM FAQ Misc Milters
Overview Directory Synchronization Messaging Architecture Review High Volume Mail HIPAA Policy QUICKStart Implementation Performance Tuning Training Services Overview Message Routing and
Configuration
Message Policy
Management
Connection Control /
Attack Prevention
Directory Configuration
and Management
Overview Sendmail Partners Milter Community Industry Organizations System Integrators & Distributors
Overview Silver Support Gold Support Platinum Support Open Source Support Security Advisories Contact Support
Overview Customers Events Press Room Board & Investors Management Careers Contact Us
Overview Ask the Experts Security Chalk Talks Collateral Product Reviews & Awards IP Reputation Check Real-time Outbreak Monitor
Sendmail Inc.

HOME | CUSTOMER LOGIN
Follow Sendmail on Twitter
The Sendmail Blog
Sentrion Message Processors
Sentrion Application Store
Services
Partners
Support
Company
Resources
Open Source
 
    Open Source
  • Overview
  • Download
  • Security
  • Support
  • News
  • Documentation
  • Tips and Tricks
  • DKIM
  • FAQ
  • Misc
  • Milters
  • Compiling Sendmail
  • Controlling SMTP Relaying
  • Overriding File Security Checks
  • Possible Firewall-Induced Network Problems
  • Set up DNS for your private address space
  • Virtual Hosting

Sendmail Professional Services

Overriding File Security Checks

Beginning with version 8.9.0, sendmail has tightened the rules used for opening files. Sendmail now checks the modes and ownership of the files and the directory path leading up to that file to prevent users from taking advantage of overly permissive modes on directories and files.

During your migration to sendmail 8.9, you will need to fix up any permissions which would be considered unsafe such as non-root owned directories containing maps or group writable directories and files. In general, directories which sendmail reads from should be owned by root unless the RunAsUser option is set. There are exceptions to this rule such as user .forward files.

You may have to tweak your environment to make it safer for sendmail to run. If you find that some of the safeties in sendmail are too restrictive for your environment, they can be turned off by setting the option DontBlameSendmail. The option is appropriately named as sendmail is not to be blamed for problems resulting from unsafe permissions on directories and files.

Checking your system for these unsafe files is simply a matter of performing a few commands to see if they report any problems. For example, if rebuilding the aliases file with:

# newaliases -v

gives messages such as:

WARNING: writable directory /etc WARNING: writable directory /usr/spool/mqueue

then the directories listed have inappropriate write permissions and should be secured to avoid various possible security attacks. Although somewhat verbose, a good test to make sure sendmail is satisfied with the permissions on your database maps, class files, and aliases file is the command:

# sendmail -v -d44.4 -bv postmaster

This will output the file safety checks as they are done and the results of each one.

The biggest surprise is likely to come from .forward and :include: files in unsafe directory paths (directory paths which are group or world writable). This is no longer allowed. This would mean that if user joe's home directory was writable by group staff, sendmail would not use his .forward file. This behavior can be altered, at the possible expense of system security, by setting the DontBlameSendmail option. For example, to allow forward files in group writable directories:

O DontBlameSendmail=forwardfileingroupwritabledirpath

Or to allow them in both group and world writable directories:

O DontBlameSendmail=forwardfileinunsafedirpath

Items from these unsafe .forward and :include: files will be marked as unsafe addresses -- the items can not be deliveries to files or programs. This behavior can also be altered via DontBlameSendmail:

O DontBlameSendmail=forwardfileinunsafedirpath, forwardfileinunsafedirpathsafe

The first flag allows the forward file to be read, the second allows the items in the file to be marked as safe for file and program delivery.

Other files affected by this strengthened security include class files (i.e. Fw /etc/sendmail.cw), persistent host status files, and the files specified by the ErrorHeader and HelpFile options. Similar DontBlameSendmail flags are available for these files.

The DontBlameSendmail option takes one or more names that disable checks. In the descriptions that follow, "unsafe directory" means a directory that is writable by anyone other than the owner. The values are:

Safe No special handling.
AssumeSafeChown Assume that the chown system call is restricted to root. Since some versions of UNIX permit regular users to give away their files to other users on some filesystems, sendmail often cannot assume that a given file was created by the owner, particularly when it is in a writable directory. You can set this flag if you know that file giveaway is restricted on your system.
ClassFileInUnsafeDirPath When reading class files (using the F line in the configuration file), allow files that are in unsafe directories.
DontWarnForwardFileInUnsafeDirPath Prevent logging of unsafe directory path warnings for non-existent forward files.
ErrorHeaderInUnsafeDirPath Allow the file named in the ErrorHeader option to be in an unsafe directory.
FileDeliveryToHardLink Allow delivery to files that are hard links.
FileDeliveryToSymLink Allow delivery to files that are symbolic links.
ForwardFileInGroupWritableDirPath Allow .forward files in group writable directories.
ForwardFileInUnsafeDirPath Allow .forward files in unsafe directories.
ForwardFileInUnsafeDirPathSafe Allow a .forward file that is in an unsafe directory to include references to program and files.
GroupReadableKeyFile Accept a group-readable key file for STARTTLS.
GroupReadableSASLDBFile Accept a group-readable Cyrus SASL password file.
GroupWritableAliasFile Allow group-writable alias files.
GroupWritableDirPathSafe Change the definition of "unsafe directory" to consider group-writable directories to be safe. World-writable directories are always unsafe.
GroupWritableForwardFile Allow group writable .forward files.
GroupWritableForwardFileSafe Accept group-writable .forward files.
GroupWritableIncludeFile Allow group wriable :include: files.
GroupWritableIncludeFileSafe Accept group-writable :include: files.
GroupWritableSASLDBFile Accept a group-writable Cyrus SASL password file.
HelpFileInUnsafeDirPath Allow the file named in the HelpFile option to be in an unsafe directory.
IncludeFileInGroupWritableDirPath Allow :include: files in group writable directories.
IncludeFileInUnsafeDirPath Allow :include: files in unsafe directories.
IncludeFileInUnsafeDirPathSafe Allow a :include: file that is in an unsafe directory to include references to program and files.
InsufficientEntropy Try to use STARTTLS even if the PRNG for OpenSSL is not properly seeded despite the security problems.
LinkedAliasFileInWritableDir Allow an alias file that is a link in a writable directory.
LinkedClassFileInWritableDir Allow class files that are links in writable directories.
LinkedForwardFileInWritableDir Allow .forward files that are links in writable directories.
LinkedIncludeFileInWritableDir Allow :include: files that are links in writable directories.
LinkedMapInWritableDir Allow map files that are links in writable directories.
LinkedServiceSwitchFileInWritableDir Allow the service switch file to be a link even if the directory is writable.
MapInUnsafeDirPath Allow maps (e.g., hash, btree, and dbm files) in unsafe directories.
NonRootSafeAddr Do not mark file and program deliveries as unsafe if sendmail is not running with root privileges.
RunProgramInUnsafeDirPath Go ahead and run programs that are in writable directories.
RunWritableProgram Go ahead and run programs that are group- or world-writable.
TrustStickyBit Allow group or world writable directories if the sticky bit is set on the directory. Do not set this on systems which do not honor the sticky bit on directories.
WorldWritableAliasFile Accept world-writable alias files.
WorldWritableForwardfile Allow world writable .forward files.
WorldWritableIncludefile Allow world wriable :include: files.
WriteMapToHardLink Allow writes to maps that are hard links.
WriteMapToSymLink Allow writes to maps that are symbolic links.
WriteStatsToHardLink Allow the status file to be a hard link.
WriteStatsToSymLink Allow the status file to be a symbolic link.


Site Map | Privacy Policy | Terms & Conditions | Copyright © 1998-2013 Sendmail, Inc. All Rights Reserved.