msgid ""
msgstr ""
"Project-Id-Version: 0\n"
"POT-Creation-Date: 2018-03-19 00:26+0100\n"
"PO-Revision-Date: 2018-03-19 00:26+0100\n"
"Last-Translator: Automatically generated\n"
"Language-Team: None\n"
"Language: en-US \n"
"MIME-Version: 1.0\n"
"Content-Type: application/x-publican; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Publican v4.3.2\n"

msgid "Developer's Best Practices for OS Security"
msgstr ""

msgid "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 <ulink name=\"Secure Programming for Linux and Unix HOWTO\" url=\"http://www.dwheeler.com/secure-programs/\" /> and <ulink name=\"Secure Coding: Principles and Practices\" url=\"http://www.securecoding.org\" /> by Mark G. Graff and Kenneth R. van Wyk (O'Reilly, 2003)."
msgstr ""

msgid "Best practices for security review and design"
msgstr ""

msgid "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."
msgstr ""

msgid "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 <emphasis>sixty</emphasis> 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."
msgstr ""

msgid "The programming bugs which lead to security bugs typically include: <ulink name=\"buffer overflows\" url=\"http://en.wikipedia.org/wiki/Buffer_overflow\" />, format string overflows, heap overflows and integer overflows (in C/C++ programs), temporary <ulink name=\"symlink race conditions\" url=\"http://en.wikipedia.org/wiki/Symlink_race\" /> (in scripts), <ulink name=\"directory traversal\" url=\"http://en.wikipedia.org/wiki/Directory_traversal\" /> and command injection (in servers) and <ulink name=\"cross-site scripting\" url=\"http://en.wikipedia.org/wiki/Cross_site_scripting\" />, and <ulink name=\"SQL injection bugs\" url=\"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 <ulink name=\"Taxonomy of Software Security Errors\" url=\"http://vulncat.fortifysoftware.com/\" />."
msgstr ""

msgid "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 <literal>grep -r \"/tmp/\" .</literal>. Those calls can be reviewed and replace the hardcoded filenames using temporary directories to calls to either <command>mktemp</command> or <command>tempfile</command> in shell scripts, <citerefentry><refentrytitle>File::Temp</refentrytitle> <manvolnum>3perl</manvolnum></citerefentry> in Perl scripts, or <citerefentry><refentrytitle>tmpfile</refentrytitle> <manvolnum>3</manvolnum></citerefentry> in C/C++."
msgstr ""

msgid "There are a set of tools available to assist to the security code review phase. These include <package>rats</package>, <package>flawfinder</package> and <package>pscan</package>. For more information, read the <ulink name=\"list of tools used by the Debian Security Audit Team\" url=\"http://www.debian.org/security/audit/tools\" />."
msgstr ""

msgid "When packaging software developers have to make sure that they follow common security principles, including:"
msgstr ""

msgid "The software runs with the minimum privileges it needs:"
msgstr ""

msgid "The package does install binaries setuid or setgid. <command>Lintian</command> will warn of <ulink name=\"setuid\" url=\" http://lintian.debian.org/reports/Tsetuid-binary.html\" />, <ulink name=\"setgid\" url=\"http://lintian.debian.org/reports/Tsetgid-binary.html\" /> and <ulink name=\"setuid and setgid\" url=\"http://lintian.debian.org/reports/Tsetuid-gid-binary.html\" /> binaries."
msgstr ""

msgid "The daemons the package provide run with a low privilege user (see <xref linkend=\"bpp-lower-privs\" />)"
msgstr ""

msgid "Programmed (i.e., <command>cron</command>) tasks running in the system do NOT run as root or, if they do, do not implement complex tasks."
msgstr ""

msgid "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 <ulink name=\"Debian Security Audit team\" url=\"http://www.debian.org/security/audit/\" />. In the case of setuid/setgid binaries, follow the Debian policy section regarding <ulink name=\"permissions and owners\" url=\"http://www.debian.org/doc/debian-policy/ch-files.html#s10.9\" />"
msgstr ""

msgid "For more information, specific to secure programming, make sure you read (or point your upstream to) <ulink name=\"Secure Programming for Linux and Unix HOWTO\" url=\"http://www.dwheeler.com/secure-programs/\" /> and the <ulink name=\"Build Security In\" url=\"https://buildsecurityin.us-cert.gov/portal/\" /> portal."
msgstr ""

msgid "Creating users and groups for software daemons"
msgstr ""

msgid "If your software runs a daemon that does not need root privileges, you need to create a user for it. There are two kind of Debian users that can be used by packages: static uids (assigned by <package>base-passwd</package>, for a list of static users in Debian see <xref linkend=\"faq-os-users\" />) and dynamic uids in the range assigned to system users."
msgstr ""

msgid "In the first case, you need to ask for a user or group id to the <package>base-passwd</package>. Once the user is available there the package needs to be distributed including a proper versioned depends to the <package>base-passwd</package> package."
msgstr ""

msgid "In the second case, you need to create the system user either in the <emphasis>preinst</emphasis> or in the <emphasis>postinst</emphasis> and make the package depend on <literal>adduser (&gt;= 3.11)</literal>."
msgstr ""

msgid "The following example code creates the user and group the daemon will run as when the package is installed or upgraded:"
msgstr ""

msgid ""
"\n"
"[...]\n"
"case \"$1\" in\n"
"  install|upgrade)\n"
"\n"
"  # If the package has default file it could be sourced, so that\n"
"  # the local admin can overwrite the defaults\n"
"\n"
"  [ -f \"/etc/default/<varname>packagename</varname>\" ] &amp;&amp; . /etc/default/<varname>packagename</varname>\n"
"\n"
"  # Sane defaults:\n"
"\n"
"  [ -z \"$SERVER_HOME\" ] &amp;&amp; SERVER_HOME=<varname>server_dir</varname>\n"
"  [ -z \"$SERVER_USER\" ] &amp;&amp; SERVER_USER=<varname>server_user</varname>\n"
"  [ -z \"$SERVER_NAME\" ] &amp;&amp; SERVER_NAME=\"<varname>Server description</varname>\"\n"
"  [ -z \"$SERVER_GROUP\" ] &amp;&amp; SERVER_GROUP=<varname>server_group</varname>\n"
"\n"
"  # Groups that the user will be added to, if undefined, then none.\n"
"  ADDGROUP=\"\"\n"
"\n"
"  # create user to avoid running server as root\n"
"  # 1. create group if not existing\n"
"  if ! getent group | grep -q \"^$SERVER_GROUP:\" ; then\n"
"     echo -n \"Adding group $SERVER_GROUP..\"\n"
"     addgroup --quiet --system $SERVER_GROUP 2&gt;/dev/null ||true\n"
"     echo \"..done\"\n"
"  fi\n"
"  # 2. create homedir if not existing\n"
"  test -d $SERVER_HOME || mkdir $SERVER_HOME\n"
"  # 3. create user if not existing\n"
"  if ! getent passwd | grep -q \"^$SERVER_USER:\"; then\n"
"    echo -n \"Adding system user $SERVER_USER..\"\n"
"    adduser --quiet \\\n"
"            --system \\\n"
"            --ingroup $SERVER_GROUP \\\n"
"            --no-create-home \\\n"
"            --disabled-password \\\n"
"            $SERVER_USER 2&gt;/dev/null || true\n"
"    echo \"..done\"\n"
"  fi\n"
"  # 4. adjust passwd entry\n"
"  usermod -c \"$SERVER_NAME\" \\\n"
"          -d $SERVER_HOME   \\\n"
"          -g $SERVER_GROUP  \\\n"
"             $SERVER_USER\n"
"  # 5. adjust file and directory permissions\n"
"  if ! dpkg-statoverride --list $SERVER_HOME &gt;/dev/null\n"
"  then\n"
"      chown -R $SERVER_USER:adm $SERVER_HOME\n"
"      chmod u=rwx,g=rxs,o= $SERVER_HOME\n"
"  fi\n"
"  # 6. Add the user to the ADDGROUP group\n"
"  if test -n $ADDGROUP\n"
"  then\n"
"      if ! groups $SERVER_USER | cut -d: -f2 | \\\n"
"         grep -qw $ADDGROUP; then\n"
"           adduser $SERVER_USER $ADDGROUP\n"
"      fi\n"
"  fi\n"
"  ;;\n"
"  configure)\n"
"\n"
"[...]"
msgstr ""

msgid "You have to make sure that the init.d script file:"
msgstr ""

msgid "Starts the daemon dropping privileges: if the software does not do the <citerefentry><refentrytitle>setuid</refentrytitle> <manvolnum>2</manvolnum></citerefentry> or <citerefentry><refentrytitle>seteuid</refentrytitle> <manvolnum>2</manvolnum></citerefentry> call itself, you can use the <literal>--chuid</literal> call of <command>start-stop-daemon</command>."
msgstr ""

msgid "Stops the daemon only if the user id matches, you can use the <command>start-stop-daemon</command> <literal>--user</literal> option for this."
msgstr ""

msgid "Does not run if either the user or the group do not exist:"
msgstr ""

msgid ""
"\n"
"  if ! getent passwd | grep -q \"^<varname>server_user</varname>:\"; then\n"
"     echo \"Server user does not exist. Aborting\" &gt;&amp;2\n"
"     exit 1\n"
"  fi\n"
"  if ! getent group | grep -q \"^<varname>server_group</varname>:\" ; then\n"
"     echo \"Server group does not exist. Aborting\" &gt;&amp;2\n"
"     exit 1\n"
"  fi"
msgstr ""

msgid "If the package creates the system user it can remove it when it is purged in its <emphasis>postrm</emphasis>. This has some drawbacks, however. For example, files created by it will be orphaned and might be taken over by a new system user in the future if it is assigned the same uid<footnote><para>Some relevant threads discussing these drawbacks include <ulink url=\"http://lists.debian.org/debian-mentors/2004/10/msg00338.html\" /> and <ulink url=\"http://lists.debian.org/debian-devel/2004/05/msg01156.html\" /></para> </footnote>. Consequently, removing system users on purge is not yet mandatory and depends on the package needs. If unsure, this action could be handled by asking the administrator for the prefered action when the package is installed (i.e. through <command>debconf</command>)."
msgstr ""

msgid "Maintainers that want to remove users in their <emphasis>postrm</emphasis> scripts are referred to the <command>deluser</command>/<command>deluser</command> <literal>--system</literal> option."
msgstr ""

msgid "Running programs with a user with limited privileges makes sure that any security issue will not be able to damage the full system. It also follows the principle of <emphasis>least privilege</emphasis>. Also consider you can limit privileges in programs through other mechanisms besides running as non-root<footnote><para>You can even provide a SELinux policy for it</para></footnote>. For more information, read the <ulink name=\"Minimize Privileges\" url=\"http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/minimize-privileges.html\" /> chapter of the <emphasis>Secure Programming for Linux and Unix HOWTO</emphasis> book."
msgstr ""