Subject: Avoiding gender-specific language Package: securing-howto Severity: minor Tags: patch
Dear Maintainer,
*** Please consider answering these questions, where appropriate ***
* What led up to the situation?
I was searching for gender-specific language to correct across all the
documentation that is part of DDP
* What exactly did you do (or not do) that was effective (or
ineffective)?
grep -r " he " ./* | grep .sgml
grep -r " his " ./* | grep .sgml
grep -r " him " ./* | grep .sgml
and ignored all the files that were included in a language-specific
folder other than english
* What was the outcome of this action?
I found some issues and created the patch attached here.
All the best,
Myriam
-- System Information:
Debian Release: 7.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-4-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Index: de/intro.sgml =================================================================== --- de/intro.sgml (revision 10421) +++ de/intro.sgml (working copy) @@ -960,7 +960,7 @@ Debian GNU/Linux related to resource starvation) <item>As suggested by Julián Muñoz, provided more information on the -default Debian umask and what a user can access if he has been given a +default Debian umask and what a user can access if given a shell in the system (scary, huh?) <item>Included a note in the BIOS password section due to a comment Index: en/after-install.sgml =================================================================== --- en/after-install.sgml (revision 10421) +++ en/after-install.sgml (working copy) @@ -558,8 +558,8 @@ <p>However, many script kiddies have exploits which try to create and execute files in <file>/tmp</file>. If they do not have a clue, they will fall into this pit. In other words, a user cannot be tricked into executing a trojanized -binary in <file>/tmp</file> e.g. when he incidentally adds <file>/tmp</file> -into his PATH. +binary in <file>/tmp</file> e.g. when <file>/tmp</file> is accidentally added +into the local PATH. <p>Also be forewarned, some script might depend on <file>/tmp</file> being executable. Most notably, Debconf has (had?) some issues regarding @@ -677,7 +677,7 @@ <p>PAM offers you the possibility to go through several authentication steps at once, without the user's knowledge. You could authenticate against a Berkeley database and against the normal <file>passwd</file> file, -and the user only logs in if he authenticates correct in both. +and the user only logs in if the authentication succeeds in both. You can restrict a lot with PAM, just as you can open your system doors very wide. So be careful. A typical configuration line has a control field as its second element. <!-- Second in mine (old Debian v2.0 though), check this! (FIXME) (era) --> @@ -779,7 +779,7 @@ <p>Please note that these restrictions apply to all users but <em>not</em> to the password changes done by the root user. The root user will -be able to set up any password (any length or complexity) for himself or others +be able to set up any password (any length or complexity) for personal use or others regardless of the restrictions defined here. <sect2 id="pam-rootaccess">User access control in PAM @@ -804,7 +804,7 @@ <sect2 id="pam-limits">User limits in PAM -<p> he following line should be enabled in <file>/etc/pam.d/login</file> +<p> The following line should be enabled in <file>/etc/pam.d/login</file> to set up user resource limits. <example> @@ -838,7 +838,7 @@ <p>If you want only certain users to authenticate at a PAM service, this is quite easy to achieve by using files where the users who are allowed to login (or not) are stored. Imagine you only want to allow -user 'ref' to log in via <prgn>ssh</prgn>. So you put him into +users 'ref' to log in via <prgn>ssh</prgn>. So you put them into <file>/etc/sshusers-allowed</file> and write the following into <file>/etc/pam.d/ssh</file>: @@ -1158,9 +1158,8 @@ <p> <prgn>sudo</prgn> allows the user to execute defined commands under another user's identity, even as root. If the user is added to -<file>/etc/sudoers</file> and authenticates himself correctly, he is -able to run commands which have been defined in -<file>/etc/sudoers</file>. Violations, such as incorrect passwords or +<file>/etc/sudoers</file> and authenticates correctly, the commands defined in +<file>/etc/sudoers</file> get enabled. Violations, such as incorrect passwords or trying to run a program you don't have permission for, are logged and mailed to root. @@ -1311,9 +1310,8 @@ the user's <file>.profile</file>. But then you would need to setup permissions properly in such a way that prevents the user from modifying this file. This includes: having the user's -home directories <em>not</em> belong to the user (since he would -be able to remove the file otherwise) but at the same time enable them -to read the <file>.profile</file> configuration file and write on the +home directories <em>not</em> belong to the user (since the user would +be able to remove the file otherwise) but at the same time allow the user to read the <file>.profile</file> configuration file and write on the <file>.bash_history</file>. It would be good to set the <em>immutable</em> flag (also using <prgn>chattr</prgn>) for <file>.profile</file> too if you do it this way. @@ -1381,7 +1379,7 @@ you set this value to no, although it is not recommended</p></footnote>) creates one group per user so that only the user is included in its group. Consequently 027 and 077 are equivalent as the user's group contains only the -user himself. +user. <p>This change is set by defining a proper <tt>umask</tt> setting for all users. You can change this by introducing an <prgn>umask</prgn> call @@ -1469,7 +1467,7 @@ </example> <p>The output is the list of files that a user can <em>see</em> and -the directories to which he has access. +the accessable directories. <sect2 id="limit-user-perm">Limiting access to other user's information @@ -1563,7 +1561,7 @@ <p>A system administrator must, given a big number of users, check if the passwords they have are consistent with the local security -policy. How to check? Try to crack them as an attacker would if he had +policy. How to check? Try to crack them as an attacker would if having access to the hashed passwords (the <file>/etc/shadow</file> file). <p>An administrator can use <package>john</package> or <package>crack</package> @@ -1587,7 +1585,7 @@ <item>because the user's console might be unlocked and can be accessed by an intruder. -<item>because an attacker might be able to re-attach himself to a +<item>because an attacker might be able to re-attach to a closed network connection and send commands to the remote shell (this is fairly easy if the remote shell is not encrypted as in the case of <prgn>telnet</prgn>). @@ -1887,7 +1885,7 @@ <p>A loghost is a host which collects syslog data remotely over the network. If one of your machines is cracked, the intruder is not able -to cover his tracks, unless he hacks the loghost as well. So, the +to cover the tracks, unless hacking the loghost as well. So, the loghost should be especially secure. Making a machine a loghost is simple. Just start the <prgn>syslogd</prgn> with <tt>syslogd -r</tt> and a new loghost is born. In order to do this permanently in Debian, edit @@ -1938,7 +1936,7 @@ change or disable are not worth much in the event of an intrusion. Also, you have to take into account that log files might reveal quite a lot of information about your system to an intruder -if he has access to them. +who has access to them. <!-- It should be explained why after installation this is not already done, jfs --> @@ -2331,9 +2329,7 @@ superuser can already use the basic Unix permissions to restrict access to a file, and an intruder that would get access to the superuser account could always use the <prgn>chattr</prgn> program to -remove the attribute. Such an intruder may first be confused when he -sees that he is not able to remove a file, but you should not assume -that he is blind - after all, he got into your system! Some manuals +remove the attribute. Such an intruder may first be confused when noticing not being able to remove a file, but you should not assume blindness - after all, the intruder got into your system! Some manuals (including a previous version of this document) suggest to simply remove the <prgn>chattr</prgn> and <prgn>lsattr</prgn> programs from the system to increase security, but this kind of strategy, also known @@ -2365,7 +2361,7 @@ <p> Now that the capability has been removed from the system, an intruder cannot change any attribute on the protected files, and thus cannot -change or remove the files. If he forces the machine to reboot (which +change or remove the files. If the machine is forced to reboot (which is the only way to restore the capabilities bounding set), it will easily be detected, and the capability will be removed again as soon as the system restarts anyway. The only way to change a protected file @@ -2415,8 +2411,7 @@ <prgn>locate</prgn> with the package <package>slocate</package>. slocate is labeled as a security enhanced version of GNU locate, but it actually provides additional file-locating functionality. -When using <prgn>slocate</prgn>, the user only sees the files he really -has access to and you can exclude any files or directories on the +When using <prgn>slocate</prgn>, the user only sees the actually accessible files and you can exclude any files or directories on the system. The <package>slocate</package> package runs its update process with higher privledges than locate, and indexes every file. Users are then able to quickly search for every file which they are @@ -2447,7 +2442,7 @@ but, instead keeps daily copies of the changes in <file>/var/log/setuid.changes</file>. You should set the MAILTO variable (in <file>/etc/checksecurity.conf</file>) to 'root' to -have this information mailed to him. See <manref +have this information mailed to the superuser. See <manref name="checksecurity" section="8"> for more configuration info. <sect id="network-secure">Securing network access @@ -2814,7 +2809,7 @@ within the same (local) network. <footnote> An attacker might have many problems pulling the access through -after configuring the IP-address binding if he is not on the same +after configuring the IP-address binding while not being on the same broadcast domain (same network) as the attacked host. If the attack goes through a router it might be quite difficult for the answers to return somewhere. Index: en/faq.sgml =================================================================== --- en/faq.sgml (revision 10421) +++ en/faq.sgml (working copy) @@ -15,7 +15,7 @@ <em>secure</em>, but may not be as paranoid as some other operating systems which install all services <em>disabled by default</em>. In any case, the system administrator needs to adapt the security of the -system to his local security policy. +system to the local security policy. <p>For a collection of data regarding security vulnerabilities for many operating systems, see the @@ -1032,7 +1032,7 @@ or more members review it and consider its impact on the stable release of Debian (i.e. if it's vulnerable or not). If our system is vulnerable, we work on a fix for the problem. The package maintainer is -contacted as well, if he didn't contact the Security Team already. +contacted as well, if the Security Team hadn't been already contacted. Finally, the fix is tested and new packages are prepared, which then are compiled on all stable architectures and uploaded afterwards. After all of that is done, an advisory is published. Index: en/intro.sgml =================================================================== --- en/intro.sgml (revision 10421) +++ en/intro.sgml (working copy) @@ -1018,7 +1018,7 @@ Debian GNU/Linux related to resource starvation). <item>As suggested by Julián Muñoz, provided more information on the -default Debian umask and what a user can access if he has been given a +default Debian umask and what a user can access if given a shell in the system (scary, huh?). <item>Included a note in the BIOS password section due to a comment Index: en/services.sgml =================================================================== --- en/services.sgml (revision 10421) +++ en/services.sgml (working copy) @@ -1247,8 +1247,8 @@ restrict a daemon or a user or another service. Just imagine a jail around your target, which the target cannot escape from (normally, but there are still a lot of conditions that allow one to escape out of -such a jail). If you do not trust a user or a service, you can create -a modified root environment for him. This can use quite a bit of disk +such a jail). You can eventually create +a modified root environment for the user or service you do not trust. This can use quite a bit of disk space as you need to copy all needed executables, as well as libraries, into the jail. But then, even if the user does something malicious, the scope of the damage is limited to the jail. @@ -1542,7 +1542,7 @@ <p>Of course, the configuration of the firewall is always system and network dependant. An administrator must know beforehand what is the -network layout and the systems he wants to protect, the services that +network layout and the systems to protect, the services that need to be accessed, and whether or not other network considerations (like NAT or routing) need to be taken into account. Be careful when configuring your firewall, as Laurence J. Lane says in the @@ -1551,9 +1551,9 @@ <p><em>The tools can easily be misused, causing enormous amounts of grief by completely crippling network access to a system. It is not terribly uncommon for a remote system administrator to -accidentally lock himself out of a system hundreds or thousands of -miles away. One can even manage to lock himself out of a computer -who's keyboard is under his fingers. Please, use due caution.</em> +accidentally get locked out of a system hundreds or thousands of +miles away. You can even manage to get locked out of a computer +who's keyboard is under your own fingers. Please, use due caution.</em> <p>Remember this: just installing the <package>iptables</package> (or the older firewalling code) does not give you any protection, just
signature.asc
Description: OpenPGP digital signature
