Product SiteDocumentation Site

Capitolo 9. Linee guida consigliate agli sviluppatori per la sicurezza del sistema operativo

9.1. Tecniche raccomandate per i controlli sulla sicurezza del software e sulla progettazione di software sicuro
9.2. Creazione di utenti e gruppi che verranno usati dai demoni
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 http://www.dwheeler.com/secure-programs/ and http://www.securecoding.org by Mark G. Graff and Kenneth R. van Wyk (O'Reilly, 2003).

9.1. Tecniche raccomandate per i controlli sulla sicurezza del software e sulla progettazione di software sicuro

Gli sviluppatori che creano dei pacchetti debian dovrebbero fare del loro meglio per assicurarsi che l'uso o l'installazione del software di cui stanno creando il pacchetto Debian non introduca delle falle di sicurezza sul sistema in cui viene installato e non comporti dei rischi di sicurezza per i suoi utenti.
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 distributing a new version. It is acknowledged that the cost of fixing 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: http://en.wikipedia.org/wiki/Buffer_overflow, format string overflows, heap overflows and integer overflows (in C/C++ programs), temporary http://en.wikipedia.org/wiki/Symlink_race (in scripts), http://en.wikipedia.org/wiki/Directory_traversal and command injection (in servers) and http://en.wikipedia.org/wiki/Cross_site_scripting, and http://en.wikipedia.org/wiki/SQL_injection (in the case of web-oriented applications). For a more complete information on security bugs review Fortify's 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 http://www.debian.org/security/audit/tools.
Se dovete pacchettizzare un software sarà bene che vi ricordiate di seguire le più comuni linee guida sulla sicurezza, tra cui:
If you have to do any of the above make sure the programs that might run with higher privileges have been audited for security bugs. If you are unsure, or need help, contact the http://www.debian.org/security/audit/. In the case of setuid/setgid binaries, follow the Debian policy section regarding 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) http://www.dwheeler.com/secure-programs/ and the https://buildsecurityin.us-cert.gov/portal/ portal.