White space fix only. Translators can ignore.
Sponsored by: iXsystems
This commit is contained in:
Dru Lavigne
parent
bf62664294
commit
bb698042d3
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=44404
1 changed files with 307 additions and 312 deletions
|
|
@ -2514,12 +2514,12 @@ racoon_enable="yes"</programlisting>
|
|||
compatible with both <acronym>SSH</acronym> version 1 and 2
|
||||
protocols.</para>
|
||||
|
||||
<para>When data is sent over the network in an unencrypted form,
|
||||
network sniffers anywhere in between the client and server
|
||||
can steal user/password information or data transferred
|
||||
during the session. <application>OpenSSH</application> offers
|
||||
a variety of authentication and encryption methods to prevent
|
||||
this from happening.</para>
|
||||
<para>When data is sent over the network in an unencrypted form,
|
||||
network sniffers anywhere in between the client and server can
|
||||
steal user/password information or data transferred during the
|
||||
session. <application>OpenSSH</application> offers a variety of
|
||||
authentication and encryption methods to prevent this from
|
||||
happening.</para>
|
||||
|
||||
<sect2>
|
||||
<title>Using the SSH Client Utilities</title>
|
||||
|
|
@ -2587,14 +2587,14 @@ COPYRIGHT 100% |*****************************| 4735
|
|||
arguments takes the form
|
||||
<option>user@host:<path_to_remote_file></option>.</para>
|
||||
|
||||
<sect3 xml:id="security-ssh-keygen">
|
||||
<title>Key-based Authentication</title>
|
||||
<sect3 xml:id="security-ssh-keygen">
|
||||
<title>Key-based Authentication</title>
|
||||
|
||||
<para>Instead of using passwords, &man.ssh-keygen.1; can be used
|
||||
to generate <acronym>DSA</acronym> or <acronym>RSA</acronym>
|
||||
keys to authenticate a user:</para>
|
||||
<para>Instead of using passwords, &man.ssh-keygen.1; can be
|
||||
used to generate <acronym>DSA</acronym> or
|
||||
<acronym>RSA</acronym> keys to authenticate a user:</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>ssh-keygen -t <replaceable>dsa</replaceable></userinput>
|
||||
<screen>&prompt.user; <userinput>ssh-keygen -t <replaceable>dsa</replaceable></userinput>
|
||||
Generating public/private dsa key pair.
|
||||
Enter file in which to save the key (/home/user/.ssh/id_dsa):
|
||||
Created directory '/home/user/.ssh'.
|
||||
|
|
@ -2605,179 +2605,182 @@ Your public key has been saved in /home/user/.ssh/id_dsa.pub.
|
|||
The key fingerprint is:
|
||||
bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com</screen>
|
||||
|
||||
<para>&man.ssh-keygen.1; will create a public and private key
|
||||
pair for use in authentication. The private key is stored
|
||||
in <filename>~/.ssh/id_dsa</filename> or
|
||||
<filename>~/.ssh/id_rsa</filename>, whereas the public key
|
||||
is stored in <filename>~/.ssh/id_dsa.pub</filename> or
|
||||
<filename>~/.ssh/id_rsa.pub</filename>, respectively for the
|
||||
<acronym>DSA</acronym> and <acronym>RSA</acronym> key types.
|
||||
The public key must be placed in
|
||||
<filename>~/.ssh/authorized_keys</filename> on the
|
||||
remote machine for both <acronym>RSA</acronym> or
|
||||
<acronym>DSA</acronym> keys in order for the setup to
|
||||
work.</para>
|
||||
<para>&man.ssh-keygen.1; will create a public and private key
|
||||
pair for use in authentication. The private key is stored
|
||||
in <filename>~/.ssh/id_dsa</filename> or
|
||||
<filename>~/.ssh/id_rsa</filename>, whereas the public key
|
||||
is stored in <filename>~/.ssh/id_dsa.pub</filename> or
|
||||
<filename>~/.ssh/id_rsa.pub</filename>, respectively for the
|
||||
<acronym>DSA</acronym> and <acronym>RSA</acronym> key types.
|
||||
The public key must be placed in
|
||||
<filename>~/.ssh/authorized_keys</filename> on the remote
|
||||
machine for both <acronym>RSA</acronym> or
|
||||
<acronym>DSA</acronym> keys in order for the setup to
|
||||
work.</para>
|
||||
|
||||
<para>This setup allows connections to the remote machine based
|
||||
upon <acronym>SSH</acronym> keys instead of passwords.</para>
|
||||
<para>This setup allows connections to the remote machine
|
||||
based upon <acronym>SSH</acronym> keys instead of
|
||||
passwords.</para>
|
||||
|
||||
<warning>
|
||||
<para>Many users believe that keys are secure by design and
|
||||
will use a key without a passphrase. This is
|
||||
<emphasis>dangerous</emphasis> behavior and the method
|
||||
an administrator may use to verify keys have a passphrase
|
||||
is to view the key manually. If the private key file
|
||||
contains the word <literal>ENCRYPTED</literal> the key
|
||||
owner is using a passphrase. While it may still be a weak
|
||||
passphrase, at least if the system is compromised, access
|
||||
to other sites will still require some level of password
|
||||
guessing. In addition, to better secure end users, the
|
||||
<literal>from</literal> may be placed in the public key
|
||||
file. For example, adding
|
||||
<literal>from="192.168.10.5</literal> in the front of
|
||||
<literal>ssh-rsa</literal> or <literal>rsa-dsa</literal>
|
||||
prefix will only allow that specific user to login from
|
||||
that host <acronym>IP</acronym>.</para>
|
||||
</warning>
|
||||
<warning>
|
||||
<para>Many users believe that keys are secure by design and
|
||||
will use a key without a passphrase. This is
|
||||
<emphasis>dangerous</emphasis> behavior and the method an
|
||||
administrator may use to verify keys have a passphrase is
|
||||
to view the key manually. If the private key file
|
||||
contains the word <literal>ENCRYPTED</literal> the key
|
||||
owner is using a passphrase. While it may still be a weak
|
||||
passphrase, at least if the system is compromised, access
|
||||
to other sites will still require some level of password
|
||||
guessing. In addition, to better secure end users, the
|
||||
<literal>from</literal> may be placed in the public key
|
||||
file. For example, adding
|
||||
<literal>from="192.168.10.5</literal> in the front of
|
||||
<literal>ssh-rsa</literal> or <literal>rsa-dsa</literal>
|
||||
prefix will only allow that specific user to login from
|
||||
that host <acronym>IP</acronym>.</para>
|
||||
</warning>
|
||||
|
||||
<warning>
|
||||
<para>The various options and files can be different according
|
||||
to the <application>OpenSSH</application> version. To avoid
|
||||
problems, consult &man.ssh-keygen.1;.</para>
|
||||
</warning>
|
||||
<warning>
|
||||
<para>The various options and files can be different
|
||||
according to the <application>OpenSSH</application>
|
||||
version. To avoid problems, consult
|
||||
&man.ssh-keygen.1;.</para>
|
||||
</warning>
|
||||
|
||||
<para>If a passphrase is used in &man.ssh-keygen.1;, the user
|
||||
will be prompted for the passphrase each time in order to use
|
||||
the private key. To load <acronym>SSH</acronym> keys into memory for use,
|
||||
without needing to type the passphrase each time, use
|
||||
&man.ssh-agent.1; and &man.ssh-add.1;.</para>
|
||||
<para>If a passphrase is used in &man.ssh-keygen.1;, the user
|
||||
will be prompted for the passphrase each time in order to
|
||||
use the private key. To load <acronym>SSH</acronym> keys
|
||||
into memory for use, without needing to type the passphrase
|
||||
each time, use &man.ssh-agent.1; and &man.ssh-add.1;.</para>
|
||||
|
||||
<para>Authentication is handled by &man.ssh-agent.1;, using the
|
||||
private key(s) that are loaded into it. Then,
|
||||
&man.ssh-agent.1; should be used to launch another
|
||||
application. At the most basic level, it could spawn a shell
|
||||
or a window manager.</para>
|
||||
<para>Authentication is handled by &man.ssh-agent.1;, using
|
||||
the private key(s) that are loaded into it. Then,
|
||||
&man.ssh-agent.1; should be used to launch another
|
||||
application. At the most basic level, it could spawn a
|
||||
shell or a window manager.</para>
|
||||
|
||||
<para>To use &man.ssh-agent.1; in a shell, start it with a shell
|
||||
as an argument. Next, add the identity by running
|
||||
&man.ssh-add.1; and providing it the passphrase for the
|
||||
private key. Once these steps have been completed, the user
|
||||
will be able to &man.ssh.1; to any host that has the
|
||||
corresponding public key installed. For example:</para>
|
||||
<para>To use &man.ssh-agent.1; in a shell, start it with a
|
||||
shell as an argument. Next, add the identity by running
|
||||
&man.ssh-add.1; and providing it the passphrase for the
|
||||
private key. Once these steps have been completed, the user
|
||||
will be able to &man.ssh.1; to any host that has the
|
||||
corresponding public key installed. For example:</para>
|
||||
|
||||
<screen>&prompt.user; ssh-agent <replaceable>csh</replaceable>
|
||||
<screen>&prompt.user; ssh-agent <replaceable>csh</replaceable>
|
||||
&prompt.user; ssh-add
|
||||
Enter passphrase for /home/user/.ssh/id_dsa:
|
||||
Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa)
|
||||
&prompt.user;</screen>
|
||||
|
||||
<para>To use &man.ssh-agent.1; in
|
||||
<application>&xorg;</application>, a call to &man.ssh-agent.1;
|
||||
needs to be placed in <filename>~/.xinitrc</filename>. This
|
||||
provides the &man.ssh-agent.1; services to all programs
|
||||
launched in <application>&xorg;</application>. An example
|
||||
<filename>~/.xinitrc</filename> might look like
|
||||
this:</para>
|
||||
<para>To use &man.ssh-agent.1; in
|
||||
<application>&xorg;</application>, a call to
|
||||
&man.ssh-agent.1; needs to be placed in
|
||||
<filename>~/.xinitrc</filename>. This provides the
|
||||
&man.ssh-agent.1; services to all programs launched in
|
||||
<application>&xorg;</application>. An example
|
||||
<filename>~/.xinitrc</filename> might look like this:</para>
|
||||
|
||||
<programlisting>exec ssh-agent <replaceable>startxfce4</replaceable></programlisting>
|
||||
<programlisting>exec ssh-agent <replaceable>startxfce4</replaceable></programlisting>
|
||||
|
||||
<para>This launches &man.ssh-agent.1;, which in turn launches
|
||||
<application>XFCE</application>, every time
|
||||
<application>&xorg;</application> starts. Once
|
||||
<application>&xorg;</application> has been restarted so that
|
||||
the changes can take effect, run &man.ssh-add.1; to load all
|
||||
of the <acronym>SSH</acronym> keys.</para>
|
||||
</sect3>
|
||||
<para>This launches &man.ssh-agent.1;, which in turn launches
|
||||
<application>XFCE</application>, every time
|
||||
<application>&xorg;</application> starts. Once
|
||||
<application>&xorg;</application> has been restarted so that
|
||||
the changes can take effect, run &man.ssh-add.1; to load all
|
||||
of the <acronym>SSH</acronym> keys.</para>
|
||||
</sect3>
|
||||
|
||||
<sect3 xml:id="security-ssh-tunneling">
|
||||
<title><acronym>SSH</acronym> Tunneling</title>
|
||||
<sect3 xml:id="security-ssh-tunneling">
|
||||
<title><acronym>SSH</acronym> Tunneling</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>OpenSSH</primary>
|
||||
<secondary>tunneling</secondary>
|
||||
</indexterm>
|
||||
<indexterm>
|
||||
<primary>OpenSSH</primary>
|
||||
<secondary>tunneling</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para><application>OpenSSH</application> has the ability to
|
||||
create a tunnel to encapsulate another protocol in an
|
||||
encrypted session.</para>
|
||||
<para><application>OpenSSH</application> has the ability to
|
||||
create a tunnel to encapsulate another protocol in an
|
||||
encrypted session.</para>
|
||||
|
||||
<para>The following command tells &man.ssh.1; to create a
|
||||
tunnel for &man.telnet.1;:</para>
|
||||
<para>The following command tells &man.ssh.1; to create a
|
||||
tunnel for &man.telnet.1;:</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>5023:localhost:23 user@foo.example.com</replaceable></userinput>
|
||||
<screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>5023:localhost:23 user@foo.example.com</replaceable></userinput>
|
||||
&prompt.user;</screen>
|
||||
|
||||
<para>This example uses the following options:</para>
|
||||
<para>This example uses the following options:</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><option>-2</option></term>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><option>-2</option></term>
|
||||
|
||||
<listitem>
|
||||
<para>Forces &man.ssh.1; to use version 2 to connect to
|
||||
the server.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<listitem>
|
||||
<para>Forces &man.ssh.1; to use version 2 to connect to
|
||||
the server.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-N</option></term>
|
||||
<varlistentry>
|
||||
<term><option>-N</option></term>
|
||||
|
||||
<listitem>
|
||||
<para>Indicates no command, or tunnel only. If omitted,
|
||||
&man.ssh.1; initiates a normal session.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<listitem>
|
||||
<para>Indicates no command, or tunnel only. If omitted,
|
||||
&man.ssh.1; initiates a normal session.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-f</option></term>
|
||||
<varlistentry>
|
||||
<term><option>-f</option></term>
|
||||
|
||||
<listitem>
|
||||
<para>Forces &man.ssh.1; to run in the background.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<listitem>
|
||||
<para>Forces &man.ssh.1; to run in the
|
||||
background.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>-L</option></term>
|
||||
<varlistentry>
|
||||
<term><option>-L</option></term>
|
||||
|
||||
<listitem>
|
||||
<para>Indicates a local tunnel in
|
||||
<replaceable>localport:remotehost:remoteport</replaceable>
|
||||
format.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<listitem>
|
||||
<para>Indicates a local tunnel in
|
||||
<replaceable>localport:remotehost:remoteport</replaceable>
|
||||
format.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>user@foo.example.com</option></term>
|
||||
<varlistentry>
|
||||
<term><option>user@foo.example.com</option></term>
|
||||
|
||||
<listitem>
|
||||
<para>The login name to use on the specified remote
|
||||
<acronym>SSH</acronym> server.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
<listitem>
|
||||
<para>The login name to use on the specified remote
|
||||
<acronym>SSH</acronym> server.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<para>An <acronym>SSH</acronym> tunnel works by creating a
|
||||
listen socket on <systemitem>localhost</systemitem> on the
|
||||
specified port. It then forwards any connections received on
|
||||
the local host/port via the <acronym>SSH</acronym> connection
|
||||
to the specified remote host and port.</para>
|
||||
<para>An <acronym>SSH</acronym> tunnel works by creating a
|
||||
listen socket on <systemitem>localhost</systemitem> on the
|
||||
specified port. It then forwards any connections received
|
||||
on the local host/port via the <acronym>SSH</acronym>
|
||||
connection to the specified remote host and port.</para>
|
||||
|
||||
<para>In the example, port <replaceable>5023</replaceable> on
|
||||
<systemitem>localhost</systemitem> is forwarded to port
|
||||
<replaceable>23</replaceable> on
|
||||
<systemitem>localhost</systemitem> of the remote machine.
|
||||
Since <replaceable>23</replaceable> is used by &man.telnet.1;,
|
||||
this creates an encrypted &man.telnet.1; session through an
|
||||
<acronym>SSH</acronym> tunnel.</para>
|
||||
<para>In the example, port <replaceable>5023</replaceable> on
|
||||
<systemitem>localhost</systemitem> is forwarded to port
|
||||
<replaceable>23</replaceable> on
|
||||
<systemitem>localhost</systemitem> of the remote machine.
|
||||
Since <replaceable>23</replaceable> is used by
|
||||
&man.telnet.1;, this creates an encrypted &man.telnet.1;
|
||||
session through an <acronym>SSH</acronym> tunnel.</para>
|
||||
|
||||
<para>This can be used to wrap any number of insecure TCP
|
||||
protocols such as SMTP, POP3, and FTP.</para>
|
||||
<para>This can be used to wrap any number of insecure TCP
|
||||
protocols such as SMTP, POP3, and FTP.</para>
|
||||
|
||||
<example>
|
||||
<title>Using &man.ssh.1; to Create a Secure Tunnel for
|
||||
SMTP</title>
|
||||
<example>
|
||||
<title>Using &man.ssh.1; to Create a Secure Tunnel for
|
||||
SMTP</title>
|
||||
|
||||
<screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>5025:localhost:25 user@mailserver.example.com</replaceable></userinput>
|
||||
<screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>5025:localhost:25 user@mailserver.example.com</replaceable></userinput>
|
||||
user@mailserver.example.com's password: <userinput>*****</userinput>
|
||||
&prompt.user; <userinput>telnet localhost 5025</userinput>
|
||||
Trying 127.0.0.1...
|
||||
|
|
@ -2785,14 +2788,15 @@ Connected to localhost.
|
|||
Escape character is '^]'.
|
||||
220 mailserver.example.com ESMTP</screen>
|
||||
|
||||
<para>This can be used in conjunction with &man.ssh-keygen.1;
|
||||
and additional user accounts to create a more seamless
|
||||
<acronym>SSH</acronym> tunneling environment. Keys can be
|
||||
used in place of typing a password, and the tunnels can be
|
||||
run as a separate user.</para>
|
||||
</example>
|
||||
<para>This can be used in conjunction with
|
||||
&man.ssh-keygen.1; and additional user accounts to create
|
||||
a more seamless <acronym>SSH</acronym> tunneling
|
||||
environment. Keys can be used in place of typing a
|
||||
password, and the tunnels can be run as a separate
|
||||
user.</para>
|
||||
</example>
|
||||
|
||||
<example>
|
||||
<example>
|
||||
<title>Secure Access of a POP3 Server</title>
|
||||
|
||||
<para>In this example, there is an <acronym>SSH</acronym>
|
||||
|
|
@ -2939,11 +2943,10 @@ user@unfirewalled-system.example.org's password: <userinput>*******</userinput><
|
|||
<primary>ACL</primary>
|
||||
</indexterm>
|
||||
|
||||
<para>Access Control Lists (<acronym>ACL</acronym>s)
|
||||
extend the standard &unix; permission model in a &posix;.1e
|
||||
compatible way. This permits an administrator to
|
||||
take advantage of a more fine-grained permissions
|
||||
model.</para>
|
||||
<para>Access Control Lists (<acronym>ACL</acronym>s) extend the
|
||||
standard &unix; permission model in a &posix;.1e compatible way.
|
||||
This permits an administrator to take advantage of a more
|
||||
fine-grained permissions model.</para>
|
||||
|
||||
<para>The &os; <filename>GENERIC</filename> kernel provides
|
||||
<acronym>ACL</acronym> support for <acronym>UFS</acronym> file
|
||||
|
|
@ -2956,78 +2959,76 @@ user@unfirewalled-system.example.org's password: <userinput>*******</userinput><
|
|||
<para>If this option is not compiled in, a warning message will be
|
||||
displayed when attempting to mount a file system with
|
||||
<acronym>ACL</acronym> support. <acronym>ACL</acronym>s rely on
|
||||
extended attributes which
|
||||
are natively supported in
|
||||
extended attributes which are natively supported in
|
||||
<acronym>UFS2</acronym>.</para>
|
||||
|
||||
<para>This chapter describes how to enable
|
||||
<acronym>ACL</acronym> support and provides some usage
|
||||
examples.</para>
|
||||
|
||||
<sect2>
|
||||
<title>Enabling <acronym>ACL</acronym> Support</title>
|
||||
<sect2>
|
||||
<title>Enabling <acronym>ACL</acronym> Support</title>
|
||||
|
||||
<para><acronym>ACL</acronym>s are enabled by the mount-time
|
||||
administrative flag, <option>acls</option>, which may be added
|
||||
to <filename>/etc/fstab</filename>. The mount-time flag can
|
||||
also be automatically set in a persistent manner using
|
||||
&man.tunefs.8; to modify a superblock <acronym>ACL</acronym>s
|
||||
flag in the file system header. In general, it is preferred
|
||||
to use the superblock flag for several reasons:</para>
|
||||
<para><acronym>ACL</acronym>s are enabled by the mount-time
|
||||
administrative flag, <option>acls</option>, which may be added
|
||||
to <filename>/etc/fstab</filename>. The mount-time flag can
|
||||
also be automatically set in a persistent manner using
|
||||
&man.tunefs.8; to modify a superblock <acronym>ACL</acronym>s
|
||||
flag in the file system header. In general, it is preferred
|
||||
to use the superblock flag for several reasons:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>The superblock flag cannot be
|
||||
changed by a remount using <option>mount -u</option> as it
|
||||
requires a complete <command>umount</command> and fresh <command>mount</command>.
|
||||
This means that <acronym>ACL</acronym>s cannot be enabled on
|
||||
the root file system after boot. It also means that
|
||||
<acronym>ACL</acronym> support on
|
||||
a file system cannot be changed while the system is in
|
||||
use.</para>
|
||||
</listitem>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>The superblock flag cannot be changed by a remount
|
||||
using <option>mount -u</option> as it requires a complete
|
||||
<command>umount</command> and fresh
|
||||
<command>mount</command>. This means that
|
||||
<acronym>ACL</acronym>s cannot be enabled on the root file
|
||||
system after boot. It also means that
|
||||
<acronym>ACL</acronym> support on a file system cannot be
|
||||
changed while the system is in use.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Setting the superblock flag causes the file system
|
||||
to always be mounted with <acronym>ACL</acronym>s enabled,
|
||||
even if there is not an <filename>fstab</filename> entry
|
||||
or if the devices re-order. This prevents accidental
|
||||
mounting of the file system without <acronym>ACL</acronym>
|
||||
support.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<listitem>
|
||||
<para>Setting the superblock flag causes the file system to
|
||||
always be mounted with <acronym>ACL</acronym>s enabled,
|
||||
even if there is not an <filename>fstab</filename> entry
|
||||
or if the devices re-order. This prevents accidental
|
||||
mounting of the file system without <acronym>ACL</acronym>
|
||||
support.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<note>
|
||||
<para>It is desirable to discourage accidental mounting without
|
||||
<acronym>ACL</acronym>s enabled because nasty things can
|
||||
happen if <acronym>ACL</acronym>s are enabled, then disabled,
|
||||
then re-enabled without flushing the extended attributes. In
|
||||
general, once <acronym>ACL</acronym>s are enabled on a
|
||||
file system, they should not be disabled, as the resulting file
|
||||
protections may not be compatible with those intended by the
|
||||
users of the system, and re-enabling <acronym>ACL</acronym>s
|
||||
may re-attach the previous <acronym>ACL</acronym>s to files
|
||||
that have since had their permissions changed, resulting in
|
||||
unpredictable behavior.</para>
|
||||
</note>
|
||||
<note>
|
||||
<para>It is desirable to discourage accidental mounting
|
||||
without <acronym>ACL</acronym>s enabled because nasty things
|
||||
can happen if <acronym>ACL</acronym>s are enabled, then
|
||||
disabled, then re-enabled without flushing the extended
|
||||
attributes. In general, once <acronym>ACL</acronym>s are
|
||||
enabled on a file system, they should not be disabled, as
|
||||
the resulting file protections may not be compatible with
|
||||
those intended by the users of the system, and re-enabling
|
||||
<acronym>ACL</acronym>s may re-attach the previous
|
||||
<acronym>ACL</acronym>s to files that have since had their
|
||||
permissions changed, resulting in unpredictable
|
||||
behavior.</para>
|
||||
</note>
|
||||
|
||||
<para>File systems with <acronym>ACL</acronym>s enabled will
|
||||
show a plus (<literal>+</literal>) sign in their permission
|
||||
settings:</para>
|
||||
<para>File systems with <acronym>ACL</acronym>s enabled will
|
||||
show a plus (<literal>+</literal>) sign in their permission
|
||||
settings:</para>
|
||||
|
||||
<programlisting>drwx------ 2 robert robert 512 Dec 27 11:54 private
|
||||
<programlisting>drwx------ 2 robert robert 512 Dec 27 11:54 private
|
||||
drwxrwx---+ 2 robert robert 512 Dec 23 10:57 directory1
|
||||
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>In this example,
|
||||
<filename>directory1</filename>,
|
||||
<filename>directory2</filename>, and
|
||||
<filename>directory3</filename>
|
||||
are all taking advantage of <acronym>ACL</acronym>s, whereas
|
||||
<filename>public_html</filename>
|
||||
is not.</para>
|
||||
<para>In this example, <filename>directory1</filename>,
|
||||
<filename>directory2</filename>, and
|
||||
<filename>directory3</filename> are all taking advantage of
|
||||
<acronym>ACL</acronym>s, whereas
|
||||
<filename>public_html</filename> is not.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
|
|
@ -3047,11 +3048,11 @@ drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html</programlisting>
|
|||
other::r--</screen>
|
||||
|
||||
<para>To change the <acronym>ACL</acronym> settings on this
|
||||
file, use <command>setfacl</command>. To remove all of the currently defined
|
||||
<acronym>ACL</acronym>s from a file or file system, include
|
||||
<option>-k</option>. However, the preferred method is to use
|
||||
<option>-b</option> as it leaves the basic fields required
|
||||
for <acronym>ACL</acronym>s to work.</para>
|
||||
file, use <command>setfacl</command>. To remove all of the
|
||||
currently defined <acronym>ACL</acronym>s from a file or file
|
||||
system, include <option>-k</option>. However, the preferred
|
||||
method is to use <option>-b</option> as it leaves the basic
|
||||
fields required for <acronym>ACL</acronym>s to work.</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>setfacl -k test</userinput></screen>
|
||||
|
||||
|
|
@ -3060,12 +3061,12 @@ drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html</programlisting>
|
|||
|
||||
<screen>&prompt.user; <userinput>setfacl -m u:trhodes:rwx,group:web:r--,o::--- test</userinput></screen>
|
||||
|
||||
<para>In this example, there were no
|
||||
pre-defined entries, as they were removed by the previous
|
||||
command. This command restores the default options and assigns the
|
||||
options listed. If a user or group is added which does not
|
||||
exist on the system, an <errorname>Invalid
|
||||
argument</errorname> error will be displayed.</para>
|
||||
<para>In this example, there were no pre-defined entries, as
|
||||
they were removed by the previous command. This command
|
||||
restores the default options and assigns the options listed.
|
||||
If a user or group is added which does not exist on the
|
||||
system, an <errorname>Invalid argument</errorname> error will
|
||||
be displayed.</para>
|
||||
|
||||
<para>Refer to &man.getfacl.1; and &man.setfacl.1; for more
|
||||
information about the options available for these
|
||||
|
|
@ -3494,13 +3495,13 @@ UWWemqWuz3lAZuORQ9KX
|
|||
their allocation among users, provide for system monitoring,
|
||||
and minimally track a user's commands.</para>
|
||||
|
||||
<para>Process accounting has both positive and negative points. One
|
||||
of the positives is that an intrusion may be narrowed down to
|
||||
the point of entry. A negative is the amount of logs
|
||||
<para>Process accounting has both positive and negative points.
|
||||
One of the positives is that an intrusion may be narrowed down
|
||||
to the point of entry. A negative is the amount of logs
|
||||
generated by process accounting, and the disk space they may
|
||||
require. This section walks an administrator through the
|
||||
basics of process accounting.</para>
|
||||
|
||||
require. This section walks an administrator through the basics
|
||||
of process accounting.</para>
|
||||
|
||||
<note>
|
||||
<para>If more fine-grained accounting is needed, refer to
|
||||
<xref linkend="audit"/>.</para>
|
||||
|
|
@ -3520,16 +3521,16 @@ UWWemqWuz3lAZuORQ9KX
|
|||
<para>Once enabled, accounting will begin to track information
|
||||
such as <acronym>CPU</acronym> statistics and executed
|
||||
commands. All accounting logs are in a non-human readable
|
||||
format which can be viewed using <command>sa</command>. If issued
|
||||
without any options, <command>sa</command> prints information relating to
|
||||
the number of per-user calls, the total elapsed time in
|
||||
minutes, total <acronym>CPU</acronym> and user time in
|
||||
minutes, and the average number of <acronym>I/O</acronym> operations. Refer to
|
||||
&man.sa.8; for the list of available options which control the
|
||||
output.</para>
|
||||
format which can be viewed using <command>sa</command>. If
|
||||
issued without any options, <command>sa</command> prints
|
||||
information relating to the number of per-user calls, the
|
||||
total elapsed time in minutes, total <acronym>CPU</acronym>
|
||||
and user time in minutes, and the average number of
|
||||
<acronym>I/O</acronym> operations. Refer to &man.sa.8; for
|
||||
the list of available options which control the output.</para>
|
||||
|
||||
<para>To display the commands issued
|
||||
by users, use <command>lastcomm</command>. For example, this command
|
||||
<para>To display the commands issued by users, use
|
||||
<command>lastcomm</command>. For example, this command
|
||||
prints out all usage of <command>ls</command> by <systemitem
|
||||
class="username">trhodes</systemitem> on the
|
||||
<literal>ttyp1</literal> terminal:</para>
|
||||
|
|
@ -3559,102 +3560,96 @@ UWWemqWuz3lAZuORQ9KX
|
|||
controlled through a flat file,
|
||||
<filename>/etc/login.conf</filename>. While this method
|
||||
is still supported, any changes require a multi-step process of
|
||||
editing this file in order to divide users into various group labels known as classes,
|
||||
rebuilding the resource database using
|
||||
<command>cap_mkdb</command>, making necessary changes
|
||||
to <filename>/etc/master.passwd</filename>, and rebuilding
|
||||
the password database using
|
||||
<command>pwd_mkdb</command>. This could be
|
||||
time consuming, depending upon the number of users to
|
||||
editing this file in order to divide users into various group
|
||||
labels known as classes, rebuilding the resource database using
|
||||
<command>cap_mkdb</command>, making necessary changes to
|
||||
<filename>/etc/master.passwd</filename>, and rebuilding the
|
||||
password database using <command>pwd_mkdb</command>. This
|
||||
could be time consuming, depending upon the number of users to
|
||||
configure.</para>
|
||||
|
||||
<para>Beginning with &os; 9.0-RELEASE,
|
||||
<command>rctl</command> can be used to provide a more fine-grained
|
||||
method of controlling resources limits for users. This
|
||||
command supports much more than users as it can be used to set
|
||||
resource constraints on processes, jails, and the original login
|
||||
class. These advanced features provide administrators and users
|
||||
with methods to control resources through the command line and
|
||||
to set rules on system initialization using a configuration
|
||||
<command>rctl</command> can be used to provide a more
|
||||
fine-grained method of controlling resources limits for users.
|
||||
This command supports much more than users as it can be used to
|
||||
set resource constraints on processes, jails, and the original
|
||||
login class. These advanced features provide administrators and
|
||||
users with methods to control resources through the command line
|
||||
and to set rules on system initialization using a configuration
|
||||
file.</para>
|
||||
|
||||
<sect2>
|
||||
<title>Enabling and Configuring Resource Limits</title>
|
||||
<sect2>
|
||||
<title>Enabling and Configuring Resource Limits</title>
|
||||
|
||||
<para>By default, kernel support for <command>rctl</command> is
|
||||
not built-in, meaning that the kernel will first need to be
|
||||
recompiled using the instructions in <xref
|
||||
linkend="kernelconfig"/>. Add these lines to either
|
||||
<filename>GENERIC</filename> or a custom kernel
|
||||
configuration file, then rebuild the kernel:</para>
|
||||
<para>By default, kernel support for <command>rctl</command> is
|
||||
not built-in, meaning that the kernel will first need to be
|
||||
recompiled using the instructions in <xref
|
||||
linkend="kernelconfig"/>. Add these lines to either
|
||||
<filename>GENERIC</filename> or a custom kernel configuration
|
||||
file, then rebuild the kernel:</para>
|
||||
|
||||
<programlisting>options RACCT
|
||||
<programlisting>options RACCT
|
||||
options RCTL</programlisting>
|
||||
|
||||
<para>Once the system has rebooted into the new kernel,
|
||||
<command>rctl</command> may be used to set rules for the
|
||||
system.</para>
|
||||
<para>Once the system has rebooted into the new kernel,
|
||||
<command>rctl</command> may be used to set rules for the
|
||||
system.</para>
|
||||
|
||||
<para>Rule syntax is controlled through the use of
|
||||
a subject,
|
||||
subject-id, resource,
|
||||
and action, as seen in this example
|
||||
rule:</para>
|
||||
<para>Rule syntax is controlled through the use of a subject,
|
||||
subject-id, resource, and action, as seen in this example
|
||||
rule:</para>
|
||||
|
||||
<programlisting>user:trhodes:maxproc:deny=10/user</programlisting>
|
||||
<programlisting>user:trhodes:maxproc:deny=10/user</programlisting>
|
||||
|
||||
<para>In this rule, the subject
|
||||
is <literal>user</literal>, the subject-id is
|
||||
<literal>trhodes</literal>, the resource,
|
||||
<literal>maxproc</literal>, is the maximum
|
||||
number of processes, and the
|
||||
action is <literal>deny</literal>, which blocks any
|
||||
new processes from being created. This means that the
|
||||
user, <literal>trhodes</literal>, will be constrained to no greater than
|
||||
<literal>10</literal> processes. Other possible
|
||||
actions include logging to the console, passing a
|
||||
notification to &man.devd.8;, or sending a sigterm to the
|
||||
process.</para>
|
||||
<para>In this rule, the subject is <literal>user</literal>, the
|
||||
subject-id is <literal>trhodes</literal>, the resource,
|
||||
<literal>maxproc</literal>, is the maximum number of
|
||||
processes, and the action is <literal>deny</literal>, which
|
||||
blocks any new processes from being created. This means that
|
||||
the user, <literal>trhodes</literal>, will be constrained to
|
||||
no greater than <literal>10</literal> processes. Other
|
||||
possible actions include logging to the console, passing a
|
||||
notification to &man.devd.8;, or sending a sigterm to the
|
||||
process.</para>
|
||||
|
||||
<para>Some care must be taken when adding rules. Since this user
|
||||
is constrained to <literal>10</literal> processes, this example
|
||||
will prevent the user from performing other
|
||||
tasks after logging in and executing a
|
||||
<command>screen</command> session. Once a resource limit has
|
||||
been hit, an error will be printed, as in this example:</para>
|
||||
<para>Some care must be taken when adding rules. Since this
|
||||
user is constrained to <literal>10</literal> processes, this
|
||||
example will prevent the user from performing other tasks
|
||||
after logging in and executing a
|
||||
<command>screen</command> session. Once a resource limit has
|
||||
been hit, an error will be printed, as in this example:</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>man test</userinput>
|
||||
<screen>&prompt.user; <userinput>man test</userinput>
|
||||
/usr/bin/man: Cannot fork: Resource temporarily unavailable
|
||||
eval: Cannot fork: Resource temporarily unavailable</screen>
|
||||
|
||||
<para>As another example,
|
||||
a jail can be prevented from exceeding a memory limit. This rule could be
|
||||
written as:</para>
|
||||
<para>As another example, a jail can be prevented from exceeding
|
||||
a memory limit. This rule could be written as:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>rctl -a jail:httpd:memoryuse:deny=2G/jail</userinput></screen>
|
||||
<screen>&prompt.root; <userinput>rctl -a jail:httpd:memoryuse:deny=2G/jail</userinput></screen>
|
||||
|
||||
<para>Rules will persist across reboots if they have been
|
||||
added to <filename>/etc/rctl.conf</filename>. The format is a
|
||||
rule, without the preceding command. For example, the previous
|
||||
rule could be added as:</para>
|
||||
<para>Rules will persist across reboots if they have been added
|
||||
to <filename>/etc/rctl.conf</filename>. The format is a rule,
|
||||
without the preceding command. For example, the previous rule
|
||||
could be added as:</para>
|
||||
|
||||
<programlisting># Block jail from using more than 2G memory:
|
||||
<programlisting># Block jail from using more than 2G memory:
|
||||
jail:httpd:memoryuse:deny=2G/jail</programlisting>
|
||||
|
||||
<para>To remove a rule, use <command>rctl</command> to
|
||||
remove it from the list:</para>
|
||||
<para>To remove a rule, use <command>rctl</command> to remove it
|
||||
from the list:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>rctl -r user:trhodes:maxproc:deny=10/user</userinput></screen>
|
||||
<screen>&prompt.root; <userinput>rctl -r user:trhodes:maxproc:deny=10/user</userinput></screen>
|
||||
|
||||
<para>A method for removing all rules is documented in &man.rctl.8;.
|
||||
However, if removing all rules for a single user is required,
|
||||
this command may be issued:</para>
|
||||
<para>A method for removing all rules is documented in
|
||||
&man.rctl.8;. However, if removing all rules for a single
|
||||
user is required, this command may be issued:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>rctl -r user:trhodes</userinput></screen>
|
||||
<screen>&prompt.root; <userinput>rctl -r user:trhodes</userinput></screen>
|
||||
|
||||
<para>Many other resources exist which can be used to exert
|
||||
additional control over various <literal>subjects</literal>.
|
||||
See &man.rctl.8; to learn about them.</para>
|
||||
<para>Many other resources exist which can be used to exert
|
||||
additional control over various <literal>subjects</literal>.
|
||||
See &man.rctl.8; to learn about them.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
|
|
|||
Loading…
Reference in a new issue