os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Fix problem marked with "XXX" in revision 1.223 by Ceri:

Browse source 
Add an XXX comment regarding account locking procedures.  This text is
currently wrong, but the correct way to do this is currently pending a
resolution in bin/71147.

Yar resolved this issue with his modifications to pam_unix.c revision 1.52
which was later MFCed.

The fix was to rewrite portions of this section to cover the differences between
a *'red account and a *LOCKED* account.  While here, remove the comment.

Reviewed by:	ceri
This commit is contained in:
Tom Rhodes 2008-01-20 19:24:18 +00:00
parent 1f972bed40
commit c0d50d5d00
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=31328
1 changed files with 17 additions and 38 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

55
en_US.ISO8859-1/books/handbook/security/chapter.sgml
View file

@ -368,24 +368,19 @@
the <groupname>wheel</groupname> mechanism is better than having
nothing at all, it is not necessarily the safest option.</para>
<!-- XXX:
This will need updating depending on the outcome of PR bin/71147.
Personally I know what I'd like to see, which puts this in definite
need of a rewrite, but we'll have to wait and see. ceri@
-->
<para>To lock an account completely, the &man.pw.8; command should
be used:</para>
<para>An indirect way to secure staff accounts, and ultimately
<username>root</username> access is to use an alternative
login access method and
do what is known as <quote>starring</quote> out the encrypted
password for the staff accounts. Using the &man.vipw.8;
command, one can replace each instance of an encrypted password
with a single <quote><literal>*</literal></quote> character.
This command will update the <filename>/etc/master.passwd</filename>
file and user/password database to disable password-authenticated
logins.</para>
<screen>&prompt.root;<userinput>pw lock <replaceable>staff</replaceable></userinput></screen>
<para>A staff account entry such as:</para>
<para>This will prevent the user from logging in using any
mechanism, including &man.ssh.1;.</para>
<para>Another method of blocking access to accounts would be to
replace the encrypted password with a single
<quote><literal>*</literal></quote> character. This character
would never match the encrypted password and thus block user
access. For example, the following staff account:</para>
<programlisting>foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting>
@ -393,29 +388,13 @@
<programlisting>foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting>
<para>This change will prevent normal logins from occurring,
since the encrypted password will never match
<quote><literal>*</literal></quote>. With this done,
staff members must use
another mechanism to authenticate themselves such as
&man.kerberos.1; or &man.ssh.1; using a public/private key
pair. When using something like Kerberos, one generally must
secure the machines which run the Kerberos servers and your
desktop workstation. When using a public/private key pair
with ssh, one must generally secure
the machine used to login <emphasis>from</emphasis> (typically
one's workstation). An additional layer of protection can be
added to the key pair by password protecting the key pair when
creating it with &man.ssh-keygen.1;. Being able to
<quote>star</quote> out the passwords for staff accounts also
guarantees that staff members can only login through secure
access methods that you have set up. This forces all staff
members to use secure, encrypted connections for all of their
sessions, which closes an important hole used by many
intruders: sniffing the network from an unrelated,
less secure machine.</para>
<para>This will prevent the <username>foobar</username> user
from logging in using conventional methods. This method for
access restriction is flawed on sites using
<application>Kerberos</application> or in situations where the
user has set up keys with &man.ssh.1;.</para>
<para>The more indirect security mechanisms also assume that you are
<para>These security mechanisms also assume that you are
logging in from a more restrictive server to a less restrictive
server. For example, if your main box is running all sorts of
servers, your workstation should not be running any. In order for