|
Using GnuPG to encrypt automated system email
2011-08-16
The root mailbox on most unixes can be an excellent source of various
server health information. Unfortunately, sending these messages
off-system, while convenient, poses the risk of disclosing sensitive
system information. Suppose a system administrator receives an e-mail
detailing missing patches on a system that is subsequently forwarded to
a Gmail account. That message has not only traversed the Internet
unprotected, it sits on Gmail's servers unencrypted. In addition, it
may end up on a smartphone or laptop that could be lost or stolen.
The details of an implementation for protecting these messages with GNU
Privacy Guard (GPG) is outlined below. GPG provides an easy way to send
sensitive data across untrusted networks or to destinations that may
have limited security controls. Look for more GPG tips from the DRG in
the coming weeks and months!
A quick procmail recipe will empower us to do just that:
SUBJECT=`formail -xSubject:`
:0 c
*^To:.*root.*
|formail -I "" | gpg --trust-model always -ear "foo@example.org" | mail -s "$SUBJECT" foo@example.org
In case your procmail skills are a little rusty, let's walk through each
line:
- The first line utilizes the formail binary to extract the subject
of the incoming message and assign it to the bash variable
SUBJECT.
- The second line creates a copy of the message that is used later
in the recipe.
- The third line filters on messages that contain "root" in the
To: field.
- The fourth line takes a copy of the message and pipes it through a
series of command lines.
- formail -I "" will give us the message body without any
of the original headers. This output is then piped to gpg.
- gpg then encrypts the message body. We utilize
--trust-model always to prevent gpg about prompting for
an untrusted public key. The -ear flags encrypt the
message, create armored ascii output and utilize the specified
e-mail address as the recepient.
- Finally, the output from gpg is piped to the mail command to
send to the remote e-mail address.
When implementing something similar, you'll want to keep a few things in
mind.
- Since the procmail recipe runs as the mailbox user, it is not
wise to use the recipe on the root account. In fact, some MTAs
will not let you pipe messages to commands that are run as UID
0 (this is the default configuration in exim4). It is best to
forward root e-mail to a non-priveleged account for archiving
and forwarding purposes. Use your /etc/aliases file to accomplish
this.
- Ensure that you have local mail delivery enabled for your root
account and the non-priveleged account that is handling the
forwarding otherwise procmail will never see the message to
process it.
- Procmail may not be enabled in your default MTA install. Enabling
it should involve uncommenting a line or two in your MTA's
configuration file.
- Finally, it should go without saying, but make sure the
non-privelged account that does your forwarding has the proper
public key in its keyring. If it doesn't, the procmail recipe
will fail silently, leaving you scratching your head and digging
through logs.
DRG loves to hear from the community. If you have any feedback,
enhancements or fixes, drop us an e-mail or ping us on twitter.
posted at 12:00 am | permanent link
|
About DRG
Apply to DRG
Host a DRG Distro Pod
Insight & Analysis
Tools
Weekend Reads
Challenges
Security Innovation Grant
Mailing lists
DRG PGP public key
Follow us on Twitter
Feedback: dragon@dragonresearchgroup.org
Archives:
|