Distinguish directories from filenames by adding
class="directory" attributes to the former. Discussed with: jkois@
This commit is contained in:
Benedict Reuschling
parent
250b26d9b9
commit
b268753191
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=35184
1 changed files with 41 additions and 34 deletions
|
|
@ -506,8 +506,10 @@
|
|||
system are the
|
||||
suid-root and sgid binaries installed on the system. Most of
|
||||
these binaries, such as <application>rlogin</application>, reside
|
||||
in <filename>/bin</filename>, <filename>/sbin</filename>,
|
||||
<filename>/usr/bin</filename>, or <filename>/usr/sbin</filename>.
|
||||
in <filename class="directory">/bin</filename>, <filename
|
||||
class="directory">/sbin</filename>, <filename
|
||||
class="directory">/usr/bin</filename>, or <filename
|
||||
class="directory">/usr/sbin</filename>.
|
||||
While nothing is 100% safe, the system-default suid and sgid
|
||||
binaries can be considered reasonably safe. Still,
|
||||
<username>root</username> holes are occasionally found in these
|
||||
|
|
@ -650,7 +652,8 @@
|
|||
the system at a higher secure level but skip setting
|
||||
the <literal>schg</literal> flag for every system file and directory
|
||||
under the sun. Another possibility is to simply
|
||||
mount <filename>/</filename> and <filename>/usr</filename> read-only.
|
||||
mount <filename class="directory">/</filename> and <filename
|
||||
class="directory">/usr</filename> read-only.
|
||||
It should be noted that being too draconian about what is permitted
|
||||
may prevent the all-important detection of an intrusion.</para>
|
||||
</sect2>
|
||||
|
|
@ -663,9 +666,10 @@
|
|||
system configuration and control files so much before the
|
||||
convenience factor rears its ugly head. For example, using
|
||||
<command>chflags</command> to set the <literal>schg</literal> bit
|
||||
on most of the files in <filename>/</filename> and
|
||||
<filename>/usr</filename> is probably counterproductive, because
|
||||
while it may protect the files, it also closes a detection window.
|
||||
on most of the files in <filename class="directory">/</filename> and
|
||||
<filename class="directory">/usr</filename> is probably
|
||||
counterproductive, because while it may protect the files, it also
|
||||
closes a detection window.
|
||||
The last layer of your security onion is perhaps the most
|
||||
important — detection. The rest of your security is pretty
|
||||
much useless (or, worse, presents you with a false sense of
|
||||
|
|
@ -702,14 +706,14 @@
|
|||
scripts out of simple system utilities such as &man.find.1; and
|
||||
&man.md5.1;. It is best to physically md5 the client-box files
|
||||
at least once a day, and to test control files such as those
|
||||
found in <filename>/etc</filename> and
|
||||
<filename>/usr/local/etc</filename> even more often. When
|
||||
found in <filename class="directory">/etc</filename> and <filename
|
||||
class="directory">/usr/local/etc</filename> even more often. When
|
||||
mismatches are found, relative to the base md5 information the
|
||||
limited-access machine knows is valid, it should scream at a
|
||||
sysadmin to go check it out. A good security script will also
|
||||
check for inappropriate suid binaries and for new or deleted files
|
||||
on system partitions such as <filename>/</filename> and
|
||||
<filename>/usr</filename>.</para>
|
||||
on system partitions such as <filename class="directory">/</filename>
|
||||
and <filename class="directory">/usr</filename>.</para>
|
||||
|
||||
<para>When using ssh rather than NFS,
|
||||
writing the security script is much more difficult. You
|
||||
|
|
@ -1620,8 +1624,8 @@ sendmail : PARANOID : deny</programlisting>
|
|||
|
||||
<para>This is done on the Kerberos server only. First make sure that
|
||||
you do not have any old Kerberos databases around. You should change
|
||||
to the directory <filename>/etc/kerberosIV</filename> and check that
|
||||
only the following files are present:</para>
|
||||
to the directory <filename class="directory">/etc/kerberosIV</filename>
|
||||
and check that only the following files are present:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>cd /etc/kerberosIV</userinput>
|
||||
&prompt.root; <userinput>ls</userinput>
|
||||
|
|
@ -1789,11 +1793,10 @@ Edit O.K.
|
|||
<para>We now have to extract all the instances which define the
|
||||
services on each machine. For this we use the
|
||||
<command>ext_srvtab</command> command. This will create a file
|
||||
which must be copied or moved <emphasis>by secure
|
||||
means</emphasis> to each Kerberos client's
|
||||
<filename>/etc</filename> directory. This file must
|
||||
be present on each server and client, and is crucial to the
|
||||
operation of Kerberos.</para>
|
||||
which must be copied or moved <emphasis>by secure means</emphasis> to
|
||||
each Kerberos client's <filename class="directory">/etc</filename>
|
||||
directory. This file must be present on each server and client, and is
|
||||
crucial to the operation of Kerberos.</para>
|
||||
|
||||
|
||||
<screen>&prompt.root; <userinput>ext_srvtab grunt</userinput>
|
||||
|
|
@ -1815,8 +1818,8 @@ Generating 'grunt-new-srvtab'....</screen>
|
|||
safe, then copy the
|
||||
<filename><replaceable>client</replaceable>-new-srvtab</filename> to
|
||||
removable media and transport it by secure physical means. Be sure to
|
||||
rename it to <filename>srvtab</filename> in the client's
|
||||
<filename>/etc</filename> directory, and make sure it is
|
||||
rename it to <filename>srvtab</filename> in the client's <filename
|
||||
class="directory">/etc</filename> directory, and make sure it is
|
||||
mode 600:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>mv grumble-new-srvtab srvtab</userinput>
|
||||
|
|
@ -1866,8 +1869,8 @@ Edit O.K.
|
|||
have correctly edited your <filename>/etc/rc.conf</filename> then this
|
||||
will happen automatically when you reboot. This is only necessary on
|
||||
the Kerberos server. Kerberos clients will automatically get what
|
||||
they need from the <filename>/etc/kerberosIV</filename>
|
||||
directory.</para>
|
||||
they need from the <filename
|
||||
class="directory">/etc/kerberosIV</filename> directory.</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>kerberos &</userinput>
|
||||
Kerberos server starting
|
||||
|
|
@ -2669,8 +2672,8 @@ jdoe@example.org</screen>
|
|||
<application>Kerberos</application> web site
|
||||
(<ulink url="http://web.mit.edu/Kerberos/www/"></ulink>)
|
||||
is recommended. Be careful of path issues: the
|
||||
<acronym>MIT</acronym> port installs into
|
||||
<filename>/usr/local/</filename> by default, and the
|
||||
<acronym>MIT</acronym> port installs into <filename
|
||||
class="directory">/usr/local/</filename> by default, and the
|
||||
<quote>normal</quote> system applications may be run instead
|
||||
of <acronym>MIT</acronym> if your <envar>PATH</envar>
|
||||
environment variable lists the system directories first.</para>
|
||||
|
|
@ -2728,9 +2731,9 @@ kadmind5_server_enable="YES"</programlisting>
|
|||
|
||||
<para>In a multi-user environment,
|
||||
<application>Kerberos</application> is less secure.
|
||||
This is because it stores the tickets in the
|
||||
<filename>/tmp</filename> directory, which is readable by all
|
||||
users. If a user is sharing a computer with several other
|
||||
This is because it stores the tickets in the <filename
|
||||
class="directory">/tmp</filename> directory, which is readable by
|
||||
all users. If a user is sharing a computer with several other
|
||||
people simultaneously (i.e. multi-user), it is possible that
|
||||
the user's tickets can be stolen (copied) by another
|
||||
user.</para>
|
||||
|
|
@ -3662,7 +3665,8 @@ COPYRIGHT 100% |*****************************| 4735
|
|||
|
||||
<para>The system-wide configuration files for both the
|
||||
<application>OpenSSH</application> daemon and client reside
|
||||
within the <filename>/etc/ssh</filename> directory.</para>
|
||||
within the <filename class="directory">/etc/ssh</filename>
|
||||
directory.</para>
|
||||
|
||||
<para><filename>ssh_config</filename> configures the client
|
||||
settings, while <filename>sshd_config</filename> configures the
|
||||
|
|
@ -4053,10 +4057,12 @@ drwxrwx---+ 2 robert robert 512 Dec 22 10:20 directory2
|
|||
drwxrwx---+ 2 robert robert 512 Dec 27 11:57 directory3
|
||||
drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html</programlisting>
|
||||
|
||||
<para>Here we see that the <filename>directory1</filename>,
|
||||
<filename>directory2</filename>, and <filename>directory3</filename>
|
||||
directories are all taking advantage of <acronym>ACL</acronym>s. The
|
||||
<filename>public_html</filename> directory is not.</para>
|
||||
<para>Here we see that the <filename
|
||||
class="directory">directory1</filename>, <filename
|
||||
class="directory">directory2</filename>, and <filename
|
||||
class="directory">directory3</filename> directories are all taking
|
||||
advantage of <acronym>ACL</acronym>s. The <filename
|
||||
class="directory">public_html</filename> directory is not.</para>
|
||||
|
||||
<sect2>
|
||||
<title>Making Use of <acronym>ACL</acronym>s</title>
|
||||
|
|
@ -4310,9 +4316,10 @@ VII. References<co id="co-ref"></programlisting>
|
|||
look over the output from <command>ident</command> on the
|
||||
affected files will help in determining the revision.
|
||||
For ports, the version number is listed after the port name
|
||||
in <filename>/var/db/pkg</filename>. If the system does not
|
||||
sync with the &os; <acronym>CVS</acronym> repository and rebuild
|
||||
daily, chances are that it is affected.</para>
|
||||
in <filename class="directory">/var/db/pkg</filename>. If the
|
||||
system does not sync with the &os; <acronym>CVS</acronym>
|
||||
repository and rebuild daily, chances are that it is
|
||||
affected.</para>
|
||||
</callout>
|
||||
|
||||
<callout arearefs="co-corrected">
|
||||
|
|
|
|||
Loading…
Reference in a new issue