Regarding why the .forward file ban was not included in SSG, in
http://people.redhat.com/swells/scap-security-guide/RHEL6/output/table-rh...
there is the comment "The security argument is not apparent or
salient." Do you see the "no .forward files" requirement as
impacting confidentiality, integrity, or availability? The
description from the RHEL5 STIG in the above link indicates it
potentially impacts confidentiality and availability.
I carefully considered the existing security arguments and still ended
up labeling very much of the 1990s best practices items with "security
argument is not apparent or salient." Credible security arguments can
certainly be presented if they exist. Here, I felt an out-of-date or
otherwise unconvincing argument was presented, for the reasons below.
(By the way, adding notes to input/auxiliary/transition_notes.xml is an
open invitation to all.)
It mentioned "unauthorized forwarding of email" and while I have little
doubt that someone in a position of authority would like for all use of
the email "forward" button to require some kind of authorization
(perhaps some kind of standard form, for each message to be forwarded,
also per recipient), this doesn't quite seem realistic. I could not
conjure any difference in risk between piecemeal forwarding and
forwarding as a rule.
Regarding mail loops, Postfix (and other modern MTAs) include a
significant number of countermeasures to address this risk.
Are those
indications sufficient for addition to the SSG, perhaps with a low
severity?
For the security discussion (non-compliance) portion, it's certainly
worth including as a discussion point (and making available as a Rule
for parties who may have specific use cases where this might really
matter). For a baseline with a wide audience such as the STIG, I had
argued against inclusion. But if you feel that there's value in
enforcing this as a compliance check (which is to say, that the security
benefits outweigh the costs as part of maintaining the baseline as well
as of enforcement itself), please say so and throw a patch up to the list.
There is also an interesting security argument for permitting
forwarding. When remote email access to a corporate account is (often
inexplicably or lazily) denied, forwarding allows users to receive email
that has at least been santized via corporate email services. The
predictable alternative user behavior is to use entirely non-corporate
services for remote email connectivity. It is a very interesting risk
comparison.
Would "forward_path = /dev/null" in /etc/postfix/main.cf
be an adequate solution?
man(8) local tells me that should do it.
In a similar vein, should there be a "sendmail must not be
installed"
rule? ;-)
Yes! I thought that this would have carried over from the RHEL 5 USGCB
rules, but I suppose it got lost in the shuffle. I just added it, and
to the Profile too.
I've read significant amounts of both the Sendmail and Postfix code, and
I _strongly_ support this.