Control: reassign -1 harden-doc On Mi, 16 iul 14, 20:22:37, myr wrote: > 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 -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt
Attachment:
signature.asc
Description: Digital signature