It is very common nowadays to digitally sign (and sometimes encrypt) e-mail. You might, for example, find that many people participating on mailing lists sign their list e-mail. Public key signatures are currently the only means to verify that an e-mail was sent by the sender and not by some other person.
Debian GNU/Linux provides a number of e-mail clients with built-in e-mail signing capabili-ties that interoperate either with gnupg or pgp:
3Actually, there is an installer package for the F-prot antivirus, which is non-free but gratis for home users, called f-prot-installer. This installer, however, just downloads F-prot’s software (http://www.f-prot.
com/products/home_use/linux/) and installs it in the system.
• evolution.
• mutt.
• kmail.
• icedove (rebranded version of Mozilla’s Thunderbird) through the Enigmail (http://
enigmail.mozdev.org/) plugin. This plugin is provided by the enigmail package.
• sylpheed. Depending on how the stable version of this package evolves, you may need to use the bleeding edge version, sylpheed-claws.
• gnus, which when installed with the mailcrypt package, is an emacs interface to gnupg.
• kuvert, which provides this functionality independently of your chosen mail user agent (MUA) by interacting with the mail transport agent (MTA).
Key servers allow you to download published public keys so that you may verify signatures.
One such key server ishttp://wwwkeys.pgp.net. gnupg can automatically fetch public keys that are not already in your public keyring. For example, to configure gnupg to use the above key server, edit the file ~/.gnupg/options and add the following line:4
keyserver wwwkeys.pgp.net
Most key servers are linked, so that when your public key is added to one server, the addition is propagated to all the other public key servers. There is also a Debian GNU/Linux package debian-keyring, that provides all the public keys of the Debian developers. The gnupg keyrings are installed in /usr/share/keyrings/.
For more information:
• GnuPG FAQ (http://www.gnupg.org/faq.html).
• GnuPG Handbook (http://www.gnupg.org/gph/en/manual.html).
• GnuPG Mini Howto (English) (http://www.dewinter.com/gnupg_howto/
english/GPGMiniHowto.html).
• comp.security.pgp FAQ (http://www.uk.pgp.net/pgpnet/pgp-faq/).
• Keysigning Party HOWTO (http://www.cryptnet.net/fdp/crypto/
gpg-party.html).
4For more examples of how to configure gnupg check /usr/share/doc/mutt/examples/gpg.rc.
Chapter 9
Developer’s Best Practices for OS Security
This chapter introduces some best secure coding practices for developers writing Debian packages. If you are really interested in secure coding I recommend you read David Wheeler’s Secure Programming for Linux and Unix HOWTO (http://www.dwheeler.
com/secure-programs/) and Secure Coding: Principles and Practices (http://www.
securecoding.org) by Mark G. Graff and Kenneth R. van Wyk (O’Reilly, 2003).
9.1 Best practices for security review and design
Developers that are packaging software should make a best effort to ensure that the installation of the software, or its use, does not introduce security risks to either the system it is installed on or its users.
In order to do so, they should make their best to review the source code of the package and detect any flaws that might introduce security bugs before releasing the software or distribut-ing a new version. It is acknowledged that the cost of fixdistribut-ing bugs grows for different stages of its development, so it is easier (and cheaper) to fix bugs when designing than when the software has been deployed and is in maintenance mode (some studies say that the cost in this later phase is sixty times higher). Although there are some tools that try to automatically detect these flaws, developers should strive to learn about the different kind of security flaws in order to understand them and be able to spot them in the code they (or others) have written.
The programming bugs which lead to security bugs typically include: buffer overflows (http:
//en.wikipedia.org/wiki/Buffer_overflow), format string overflows, heap over-flows and integer overover-flows (in C/C++ programs), temporary symlink race conditions (http:
//en.wikipedia.org/wiki/Symlink_race) (in scripts), directory traversal (http://
en.wikipedia.org/wiki/Directory_traversal) and command injection (in servers) and cross-site scripting (http://en.wikipedia.org/wiki/Cross_site_scripting), and SQL injection bugs (http://en.wikipedia.org/wiki/SQL_injection) (in the case
of web-oriented applications). For a more complete information on security bugs review For-tify’s Taxonomy of Software Security Errors (http://vulncat.fortifysoftware.com/).
Some of these issues might not be easy to spot unless you are an expert in the programming language the software uses, but some security problems are easy to detect and fix. For example, finding temporary race conditions due to misuse of temporary directories can easily be done just by running grep -r “/tmp/” .. Those calls can be reviewed and replace the hardcoded filenames using temporary directories to calls to either mktemp or tempfile in shell scripts, File::Temp(3perl)in Perl scripts, or tmpfile(3) in C/C++.
There are a set of tools available to assist to the security code review phase. These include rats, flawfinder and pscan. For more information, read the list of tools used by the Debian Security Audit Team (http://www.debian.org/security/audit/tools).
When packaging software developers have to make sure that they follow common security principles, including:
• The software runs with the minimum privileges it needs:
– The package does install binaries setuid or setgid. Lintian will warn of setuid (http://lintian.debian.org/reports/Tsetuid-binary.html), set-gid (http://lintian.debian.org/reports/Tsetgid-binary.html) and setuid and setgid (http://lintian.debian.org/reports/
Tsetuid-gid-binary.html) binaries.
– The daemons the package provide run with a low privilege user (see ‘Creating users and groups for software daemons’ on this page)
• Programmed (i.e., cron) tasks running in the system do NOT run as root or, if they do, do not implement complex tasks.
If you have to do any of the above make sure the programs that might run with higher priv-ileges have been audited for security bugs. If you are unsure, or need help, contact the De-bian Security Audit team (http://www.deDe-bian.org/security/audit/). In the case of setuid/setgid binaries, follow the Debian policy section regarding permissions and owners (http://www.debian.org/doc/debian-policy/ch-files.html#s10.9)
For more information, specific to secure programming, make sure you read (or point your upstream to) Secure Programming for Linux and Unix HOWTO (http://www.dwheeler.
com/secure-programs/) and the Build Security In (https://buildsecurityin.
us-cert.gov/portal/) portal.