Product SiteDocumentation Site

4.11. Providing secure user access

4.11.1. ユーザ認証: PAM

PAM (Pluggable Authentication Modules) allows system administrators to choose how applications authenticate users. Note that PAM can do nothing unless an application is compiled with support for PAM. Most of the applications that are shipped with Debian have this support built in (Debian did not have PAM support before 2.2). The current default configuration for any PAM-enabled service is to emulate UNIX authentication (read /usr/share/doc/libpam0g/Debian-PAM-MiniPolicy.gz for more information on how PAM services should work in Debian).
Each application with PAM support provides a configuration file in /etc/pam.d/ which can be used to modify its behavior:
  • what backend is used for authentication.
  • what backend is used for sessions.
  • how do password checks behave.
The following description is far from complete, for more information you might want to read the Linux-PAM Guides as a reference. This documentation is available in the system if you install the libpam-doc at /usr/share/doc/libpam-doc/html/.
PAM はユーザに知られることなくいくつかの認証の段階を一度に行うことを 可能にします。Berkeley データベースと通常の passwd ファイルで認証することが できます。両方で正しく認証された場合のみユーザはログインします。PAM で きつく制限することもできますし、システムを非常に広く開放することもできます。 だから注意してください。典型的な設定行にはコントロールフィールドが 2 番目の要素としてあります。 一般的にこれは「requisite」に設定するべきです。これはモジュールがひとつでも 失敗すればログイン失敗を返します。

4.11.2. Password security in PAM

Review the /etc/pam.d/common-password, included by /etc/pam.d/passwd[16] This file is included by other files in /etc/pam.d/ to define the behaviour of password use in subsystems that grant access to services in the machine, like the console login (login), graphical login managers (such as gdm or lightdm), and remote login (such as sshd). This definition is
You have to make sure that the pam_unix.so module uses the "sha512" option to use encrypted passwords. This is the default in Debian Squeeze.
The line with the definition of the pam_unix module will look something like:
  password   [success=1 default=ignore]      pam_unix.so nullok obscure minlen=8 sha512 
This definition:
  • Enforces password encryption when storing passwords, using the SHA-512 hash function (option sha512),
  • Enables password complexity checks (option obscure) as defined in the pam_unix(8) manpage,
  • Imposes a minimum password length (option min) of 8.
You have to ensure that encrypted passwords are used in PAM applications, since this helps protect against dictionary cracks. Using encryption also makes it possible to use passwords longer than 8 characters.
Since this module is also used to define how passwords are changed (it is included by chpasswd) you can strengthen the password security in the system by installing libpam-cracklib and introducing this definition in the /etc/pam.d/common-password configuration file:
  # Be sure to install libpam-cracklib first or you will not be able to log in
  password   required     pam_cracklib.so retry=3 minlen=12 difok=3
  password   [success=1 default=ignore]      pam_unix.so obscure minlen=8 sha512 use_authok
So, what does this incantation do? The first line loads the cracklib PAM module, which provides password strength-checking, prompts for a new password with a minimum size [17] of 12 characters, and difference of at least 3 characters from the old password, and allows 3 retries. Cracklib depends on a wordlist package (such as wenglish, wspanish, wbritish, ...), so make sure you install one that is appropriate for your language or cracklib might not be useful to you at all.
The second line (using the pam_unix.so module) is the default configuration in Debian, as described above, save for the use_authok option. The use_authok option is required if pam_unix.so is stacked after pam_cracklib.so, and is used to hand over the password from the previous module. Otherwise, the user would be prompted for the password twice.
For more information about setting up Cracklib, read the pam_cracklib(8) manpage and the article Linux Password Security with pam_cracklib by Hal Pomeranz.
By enabling the cracklib PAM module you setup a policy that forces uses to use strong passwords.
Alternatively, you can setup and configure PAM modules to use double factor authentication such as: libpam-barada, libpam-google-authenticator, libpam-oath, libpam-otpw, libpam-poldi, libpam-usb or libpam-yubico. The configuration of these modules would make it possible to access the system using external authentication mechanisms such as smartcards, external USB keys, or One-Time-Passwords generated by external applications running, for example, in the user's mobile phone.
Please note that these restrictions apply to all users but not 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 personal use or others regardless of the restrictions defined here.

4.11.3. User access control in PAM

root ユーザはローカル端末からしかログインできないようにするには、 /etc/pam.d/login で以下の行を有効にするべきです。
auth     requisite  pam_securetty.so
Then you should modify the list of terminals on which direct root login is allowed in /etc/securetty (as described in 第 4.7 節「コンソールログインのアクセスを制限する」). Alternatively, you could enable the pam_access module and modify /etc/security/access.conf which allows for a more general and fine-tuned access control, but (unfortunately) lacks decent log messages (logging within PAM is not standardized and is particularly unrewarding problem to deal with). We'll return to access.conf a little later.

4.11.4. User limits in PAM

The following line should be enabled in /etc/pam.d/login to set up user resource limits.
  session  required   pam_limits.so
これはユーザが使えるシステム資源を制限します。以下にある 第 4.11.8 節「Limiting resource usage: the limits.conf file」 をごらんください。 たとえば、(あるユーザグループの、またはシステム全体の) 同時に行える ログインの個数、プロセスの個数、メモリの大きさなどを制限できます。

4.11.5. Control of su in PAM

あなたのシステム上である人たちだけが su を使って root になれるように su を 守りたいならば、「wheel」グループをあなたのシステムに加える必要があります (これが最もきれいなやり方です。というのもまだどのファイルもそのような グループのパーミッションを持っていないからです)。root やその他の root ユーザに 「su できる」べきユーザをこのグループに加えてください。 そして以下の行を /etc/pam.d/su に加えます:
auth        requisite   pam_wheel.so group=wheel debug
これは wheel グループの人だけが root になるために su を 使えるようにします。他のユーザは root になることができません。実際、 もしその人たちが root になろうとすると拒否のメッセージを受けとることに なります。
特定のユーザだけを PAM サービスで認証したいならば、これはログインすることが 許可されている (もしくは許可されていない) ユーザが記録されているファイルを 使うことで簡単に達成できます。ユーザ「ref」だけが ssh 経由でログインできる ようにしたいとしましょう。そこで ref を /etc/sshusers-allowed に 加え、以下の内容を /etc/pam.d/ssh に書くわけです:
auth        required    pam_listfile.so item=user sense=allow file=/etc/sshusers-allowed onerr=fail

4.11.6. Temporary directories in PAM

Since there have been a number of so called insecure tempfile vulnerabilities, thttpd is one example (see DSA-883-1), the libpam-tmpdir is a good package to install. All you have to do is add the following to /etc/pam.d/common-session:
 session    optional     pam_tmpdir.so
There has also been a discussion about adding this by default in Debian configuration, but it s. See http://lists.debian.org/debian-devel/2005/11/msg00297.html for more information.

4.11.7. Configuration for undefined PAM applications

最後だからといって重要でないというわけではありませんが、 /etc/pam.d/other を作成して以下の行を入力しましょう:
auth     required       pam_securetty.so
auth     required       pam_unix_auth.so
auth     required       pam_warn.so
auth     required       pam_deny.so
account  required       pam_unix_acct.so
account  required       pam_warn.so
account  required       pam_deny.so
password required       pam_unix_passwd.so
password required       pam_warn.so
password required       pam_deny.so
session  required       pam_unix_session.so
session  required       pam_warn.so
session  required       pam_deny.so
これらの行は PAM をサポートするすべてのアプリケーションに対しよい デフォルトの設定を提供します (デフォルトではアクセスは拒否されます)。

4.11.8. Limiting resource usage: the limits.conf file

You should really take a serious look into this file. Here you can define user resource limits. In old releases this configuration file was /etc/limits.conf, but in newer releases (with PAM) the /etc/security/limits.conf configuration file should be used instead.
If you do not restrict resource usage, any user with a valid shell in your system (or even an intruder who compromised the system through a service or a daemon going awry) can use up as much CPU, memory, stack, etc. as the system can provide. This resource exhaustion problem can be fixed by the use of PAM.
There is a way to add resource limits to some shells (for example, bash has ulimit, see bash(1)), but since not all of them provide the same limits and since the user can change shells (see chsh(1)) it is better to place the limits on the PAM modules as they will apply regardless of the shell used and will also apply to PAM modules that are not shell-oriented.
Resource limits are imposed by the kernel, but they need to be configured through the limits.conf and the PAM configuration of the different services need to load the appropriate PAM. You can check which services are enforcing limits by running:
$ find /etc/pam.d/ \! -name "*.dpkg*" | xargs -- grep limits |grep -v ":#"
Commonly, login, ssh and the graphic session managers (gdm, kdm or xdm) should enforce user limits but you might want to do this in other PAM configuration files, such as cron, to prevent system daemons from taking over all system resources.
The specific limits settings you might want to enforce depend on your system's resources, that's one of the main reasons why no limits are enforced in the default installation.
For example, the configuration example below enforces a 100 process limit for all users (to prevent fork bombs) as well as a limit of 10MB of memory per process and a limit of 10 simultaneous logins. Users in the adm group have higher limits and can produce core files if they want to (there is only a soft limit).
*              soft    core            0
*              hard    core            0
*              hard    rss             1000
*              hard    memlock         1000
*              hard    nproc           100
*              -       maxlogins       1
*              hard    data            102400
*              hard    fsize           2048
@adm           hard    core            100000
@adm           hard    rss             100000
@adm           soft    nproc           2000
@adm           hard    nproc           3000
@adm           hard    fsize           100000
@adm           -       maxlogins       10
These would be the limits a default user (including system daemons) would have:
$ ulimit -a
core file size        (blocks, -c) 0
data seg size         (kbytes, -d) 102400
file size             (blocks, -f) 2048
max locked memory     (kbytes, -l) 10000
max memory size       (kbytes, -m) 10000
open files                    (-n) 1024
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 100
virtual memory        (kbytes, -v) unlimited
And these are the limits for an administrative user:
$ ulimit -a
core file size        (blocks, -c) 0
data seg size         (kbytes, -d) 102400
file size             (blocks, -f) 100000
max locked memory     (kbytes, -l) 100000
max memory size       (kbytes, -m) 100000
open files                    (-n) 1024
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 2000
virtual memory        (kbytes, -v) unlimited
For more information read:

4.11.9. User login actions: edit /etc/login.defs

The next step is to edit the basic configuration and action upon user login. Note that this file is not part of the PAM configuration, it's a configuration file honored by login and su programs, so it doesn't make sense tuning it for cases where neither of the two programs are at least indirectly called (the getty program which sits on the consoles and offers the initial login prompt does invoke login).
  FAILLOG_ENAB        yes
この変数が設定されていると、ログインの失敗がログに記録されます。力まかせの 攻撃をためしている人をつかまえるために失敗を追跡することは重要です。
  LOG_UNKFAIL_ENAB    yes
If you set this variable to 'yes' it will record unknown usernames if the login failed. It is best if you use 'no' (the default) since, otherwise, user passwords might be inadvertenly logged here (if a user mistypes and they enter their password as the username). If you set it to 'yes', make sure the logs have the proper permissions (640 for example, with an appropriate group setting such as adm).
  SYSLOG_SU_ENAB      yes
これは su の試みを syslog に記録するようにします。重要なマシン上では 非常に大切ですが、これはプライバシー問題をひきおこすかもしれないことに 注意してください。
  SYSLOG_SG_ENAB      yes
SYSLOG_SU_ENAB と同じですが sg プログラムに適用されます。
  ENCRYPT_METHOD  SHA512
As stated above, encrypted passwords greatly reduce the problem of dictionary attacks, since you can use longer passwords. This definition has to be consistent with the value defined in /etc/pam.d/common-password.

4.11.10. User login actions: edit /etc/pam.d/login

You can adjust the login configuration file to implement an stricter policy. For example, you can change the default configuration and increase the delay time between login prompts. The default configuration sets a 3 seconds delay:
auth       optional   pam_faildelay.so  delay=3000000
Increasing the delay value to a higher value to make it harder to use the terminal to log in using brute force. If a wrong password is typed in, the possible attacker (or normal user!) has to wait longer seconds to get a new login prompt, which is quite time consuming when you test passwords. For example, if you set delay=10000000, users will have to wait 10 seconds if they type a wrong password.
In this file you can also set the system to present a message to users before a user logs in. The default is disabled, as shown below:
# auth       required   pam_issue.so issue=/etc/issue
If required by your security policy, this file can be used to show a standard message indicating that access to the system is restricted and user acess is logged. This kind of disclaimer might be required in some environments and jurisdictions. To enable it, just include the relevant information in the /etc/issue[18] file and uncomment the line enabling the pam_issue.so module in /etc/pam.d/login. In this file you can also enable additional features which might be relevant to apply local security policies such as:
  • setting rules for which users can access at which times, by enabling the pam_time.so module and configuring /etc/security/time.conf accordingly (disabled by default),
  • setup login sessions to use user limits as defined in /etc/security/limits.conf (enabled by default),
  • present the user with the information of previous login information (enabled by default),
  • print a message (/etc/motd and /run/motd.dynamic) to users after login in (enabled by default),

4.11.11. Restricting ftp: editing /etc/ftpusers

このファイルは ftp を使ってホストにログインすることが許可されていない ユーザのリストを含みます。ftp を本当に許可したいときだけこのファイルを 使ってください (一般に ftp は推奨されていません。なぜならこれは平文の パスワードを使うからです)。あなたのデーモンが PAM をサポートしているなら、 特定のサービスをユーザに許可したり拒否したりするのにそれを使うことも できます。
FIXME (BUG): Is it a bug that the default ftpusers in Debian does not include all the administrative users (in base-passwd).
A convenient way to add all system accounts to the /etc/ftpusers is to run
$ awk -F : '{if ($3<1000) print $1}' /etc/passwd > /etc/ftpusers

4.11.12. su を使う

パッケージをインストールするとかユーザを追加するとかのためにあなたの システムで本当にスーパーユーザになる必要があるなら、身分を変更するために su コマンドを使うことができます。root ユーザでのログインを 避けてかわりに su を使うべきです。実際、最良の解決法は su を削除して sudo に移行することです。なぜならこれは su より多くの機能を 持つからです。しかし、su は他の多くの Unixes でより一般的です。

4.11.13. sudo を使う

sudo はユーザが root を含む他のユーザの身分で定義されたコマンドを 実行することを可能にします。もしユーザが /etc/sudoers に 追加されていて、認証が正しく行われれば、/etc/sudoers で定義された コマンドを実行することができます。パスワードをまちがえたり許可のない プログラムを実行しようとしたりといった違反は記録され root にメールで 送られます。

4.11.14. Disallow remote administrative access

You should also modify /etc/security/access.conf to disallow remote logins to administrative accounts. This way users need to invoke su (or sudo) to use any administrative powers and the appropriate audit trace will always be generated.
You need to add the following line to /etc/security/access.conf, the default Debian configuration file has a sample line commented out:
   -:wheel:ALL EXCEPT LOCAL
Remember to enable the pam_access module for every service (or default configuration) in /etc/pam.d/ if you want your changes to /etc/security/access.conf honored.

4.11.15. ユーザを制限する

サービス (pop3 メールサービスや ftp) を提供するためにローカルシステムに ユーザを作成する必要があると思うことがあるかもしれません。そうする前に、 Debian GNU/Linux での PAM の実装は libpam パッケージによって提供される いろいろな外部のディレクトリサービス (radius や ldap など) でユーザを 認証することができることを思い出してください。
ユーザを作成する必要があって、リモートからシステムにアクセスできるなら、 そのユーザがシステムにログインできるかもしれないことを考慮してください。 そのユーザに空の (/dev/null) シェル (/etc/shells 中に記載されている必要があります) を与えることによってこれを修正できます。 ユーザがシステムにアクセスできるようにしたいがその行動を制限したいならば、 /bin/rbash を使うことができます。これは bash で -r オプション (RESTRICTED SHELL bash(1) を ごらんください) を追加するのと等価です。制限されたシェルでも、対話的な プログラム (これはサブシェルの実行を許すかもしれません) にアクセスする ユーザはこの制限をかいくぐることができるかもしれないことに注意してください。
Debian currently provides in the unstable release (and might be included in the next stable releases) the pam_chroot module (in the libpam-chroot). An alternative to it is to chroot the service that provides remote logging (ssh, telnet). [19]
ユーザがシステムにアクセスできる時刻を制限したいなら /etc/security/access.conf を必要にあわぜて設定する必要が あるかもしれません。
Information on how to chroot users accessing the system through the ssh service is described in 第 B.7 節「Chroot environment for SSH.

4.11.16. User auditing

If you are really paranoid you might want to add a system-wide configuration to audit what the users are doing in your system. This sections presents some tips using diverse utilities you can use.

4.11.16.1. Input and output audit with script

You can use the script command to audit both what the users run and what are the results of those commands. You cannot setup script as a shell (even if you add it to /etc/shells). But you can have the shell initialization file run the following:
umask 077
exec script -q -a "/var/log/sessions/$USER"
Of course, if you do this system wide it means that the shell would not continue reading personal initialization files (since the shell gets overwritten by script). An alternative is to do this in the user's initialization files (but then the user could remove this, see the comments about this below)
You also need to setup the files in the audit directory (in the example /var/log/sessions/) so that users can write to it but cannot remove the file. This could be done, for example, by creating the user session files in advance and setting them with the append-only flag using chattr.
A useful alternative for sysadmins, which includes date information would be:
umask 077
exec script -q -a "/var/log/sessions/$USER-`date +%Y%m%d`"

4.11.16.2. Using the shell history file

If you want to review what does the user type in the shell (but not what the result of that is) you can setup a system-wide /etc/profile that configures the environment so that all commands are saved into a history file. The system-wide configuration needs to be setup in such a way that users cannot remove audit capabilities from their shell. This is somewhat shell specific so make sure that all users are using a shell that supports this.
For example, for bash, the /etc/profile could be set as follows [20] :
  HISTFILE=~/.bash_history
  HISTSIZE=10000
  HISTFILESIZE=999999
  # Don't let the users enter commands that are ignored
  # in the history file
  HISTIGNORE=""
  HISTCONTROL=""
  readonly HISTFILE
  readonly HISTSIZE
  readonly HISTFILESIZE
  readonly HISTIGNORE
  readonly HISTCONTROL
  export HISTFILE HISTSIZE HISTFILESIZE HISTIGNORE HISTCONTROL
For this to work, the user can only append information to .bash_history file. You need also to set the append-only option using chattr program for .bash_history for all users. [21].
Note that you could introduce the configuration above in the user's .profile. 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 not 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 .profile configuration file and write on the .bash_history. It would be good to set the immutable flag (also using chattr) for .profile too if you do it this way.

4.11.16.3. Complete user audit with accounting utilities

前の例はユーザ監査を設定する単純な例です。これは複雑なシステムでは役に 立たないかもしれません。もしあなたのシステムがそうなら、アカウント ユーティリティである acctパッケージを検討する必要が あります。これはシステム中のユーザまたはプロセスが実行するすべてのコマンドを ディスクスペースとひきかえに記録します。
アカウンティングを有効にすると、プロセスやユーザのすべての情報は /var/account/ 以下に、特に pacct 中に保存されます。 acctパッケージにはこの情報を解析する道具 (saac) を含みます。

4.11.16.4. Other user auditing methods

もしあなたが本当にパラノイドですべてのユーザのコマンドを監査したいなら、 bash のソースコードを入手し、それを編集してユーザが打ちこんだものすべてを 他のファイルに送るようにすることができます。または ttysnoop が新しい tty すべてを監視して出力をファイルにダンプするようにするように しましょう。他の役に立つプログラムは http://sourceforge.net/project/?group_id=2091 です。これはユーザ透過性を持つプログラムで、execve() システムコールの ラッパーを提供するライブラリとして働きます。実行されるどのコマンドも authpriv facility (ふつうは /var/log/auth.log に 保存されます)で syslogd を使って記録されます。 !-- FIXME: Debian package for snoopy??? -->

4.11.17. ユーザのプロファイルを調べる

ユーザがふだん何をしているのか見たいなら、そのユーザが接続して いるときに wtmp データベースを使うことができます。これは すべてのログイン情報を含みます。このファイルはいくつかのユーティリティに よって処理できますが、中でも sac は各ユーザごとにシステムに いつログインしているか表示することができます。
アカウンティングを有効にしている場合は、ユーザがシステムにいつアクセスし 何を実行しているか知るためにそれによって提供される道具を使うことができます。

4.11.18. Setting users umasks

Depending on your user policy you might want to change how information is shared between users, that is, what the default permissions of new files created by users are.
Debian's default umask setting is 022 this means that files (and directories) can be read and accessed by the user's group and by any other users in the system. This definition is set in the standard configuration file /etc/profile which is used by all shells.
If Debian's default value is too permissive for your system you will have to change the umask setting for all the shells. More restrictive umask settings include 027 (no access is allowed to new files for the other group, i.e. to other users in the system) or 077 (no access is allowed to new files to the members the user's group). Debian (by default[22]) 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.
This change is set by defining a proper umask setting for all users. You can change this by introducing an umask call in the shell configuration files: /etc/profile (source by all Bourne-compatible shells), /etc/csh.cshrc, /etc/csh.login, /etc/zshrc and probably some others (depending on the shells you have installed on your system). You can also change the UMASK setting in /etc/login.defs, Of all of these the last one that gets loaded by the shell takes precedence. The order is: the default system configuration for the user's shell (i.e. /etc/profile and other system-wide configuration files) and then the user's shell (his ~/.profile, ~/.bash_profile, etc...). Some shells, however, can be executed with a nologin value which might skip sourcing some of those files. See your shell's manpage for additional information.
For connections that make use of login the UMASK definition in /etc/login.defs is used before any of the others. However, that value does not apply to user executed programs that do not use login such as those run through su, cron or ssh.
Don't forget to review and maybe modify the dotfiles under /etc/skel/ since these will be new user's defaults when created with the adduser command. Debian default dotfiles do not include any umask call but if there is any in the dotfiles newly created users might a different value.
Note, however that users can modify their own umask setting if they want to, making it more permissive or more restricted, by changing their own dotfiles.
The libpam-umask package adjusts the users' default umask using PAM. Add the following, after installing the package, to /etc/pam.d/common-session:
session    optional     pam_umask.so umask=077
Finally, you should consider changing root's default 022 umask (as defined in /root/.bashrc) to a more strict umask. That will prevent the system administrator from inadvertenly dropping sensitive files when working as root to world-readable directories (such as /tmp) and having them available for your average user.

4.11.19. Limiting what users can see/access

FIXME: Content needed. Describe the consequences of changing packages permissions when upgrading (an admin this paranoid should chroot his users BTW) if not using dpkg-statoverride.
If you need to grant users access to the system with a shell think about it very carefully. A user can, by default unless in a severely restricted environment (like a chroot jail), retrieve quite a lot of information from your system including:
  • some configuration files in /etc. However, Debian's default permissions for some sensitive files (which might, for example, contain passwords), will prevent access to critical information. To see which files are only accessible by the root user for example
    find /etc -type f -a -perm 600 -a -uid 0
    as superuser.
  • your installed packages, either by looking at the package database, at the /usr/share/doc directory or by guessing by looking at the binaries and libraries installed in your system.
  • some log files at /var/log. Note also that some log files are only accessible to root and the adm group (try
    find /var/log -type f -a -perm 640
    ) and some are even only available to the root user (try
    find /var/log -type f -a -perm
        600 -a -uid 0
    ).
What can a user see in your system? Probably quite a lot of things, try this (take a deep breath):
  find / -type f -a -perm +006 2>/dev/null  
  find / -type d -a -perm +007 2>/dev/null
The output is the list of files that a user can see and the accessable directories.

4.11.19.1. Limiting access to other user's information

If you still grant shell access to users you might want to limit what information they can view from other users. Users with shell access have a tendency to create quite a number of files under their $HOMEs: mailboxes, personal documents, configuration of X/GNOME/KDE applications...
In Debian each user is created with one associated group, and no two users belong to the same group. This is the default behavior: when an user account is created, a group of the same name is created too, and the user is assigned to it. This avoids the concept of a common users group which might make it more difficult for users to hide information from other users.
However, users' $HOME directories are created with 0755 permissions (group-readable and world-readable). The group permissions is not an issue since only the user belongs to the group, however the world permissions might (or might not) be an issue depending on your local policy.
You can change this behavior so that user creation provides different $HOME permissions. To change the behavior for new users when they get created, change DIR_MODE in the configuration file /etc/adduser.conf to 0750 (no world-readable access).
Users can still share information, but not directly in their $HOME directories unless they change its permissions.
Note that disabling world-readable home directories will prevent users from creating their personal web pages in the ~/public_html directory, since the web server will not be able to read one component in the path - namely their $HOME directory. If you want to permit users to publish HTML pages in their ~/public_html, then change DIR_MODE to 0751. This will allow the web server to access the final public_html directory (which itself should have a mode of 0755) and provide the content published by users. Of course, we are only talking about a default configuration here; users can generally tune modes of their own files completely to their liking, or you could keep content intended for the web in a separate location which is not a subdirectory of user's $HOME directory.

4.11.20. Generating user passwords

There are many cases when an administrator needs to create many user accounts and provide passwords for all of them. Of course, the administrator could easily just set the password to be the same as the user's account name, but that would not be very sensitive security-wise. A better approach is to use a password generating program. Debian provides makepasswd, apg and pwgen packages which provide programs (the name is the same as the package) that can be used for this purpose. Makepasswd will generate true random passwords with an emphasis on security over pronounceability while pwgen will try to make meaningless but pronounceable passwords (of course this might depend on your mother language). Apg has algorithms to provide for both (there is a client/server version for this program but it is not included in the Debian package).
Passwd does not allow non-interactive assignation of passwords (since it uses direct tty access). If you want to change passwords when creating a large number of users you can create them using adduser with the --disabled-login option and then use usermod or chpasswd[23] (both from the passwd package so you already have them installed). If you want to use a file with all the information to make users as a batch process you might be better off using newusers.

4.11.21. Checking user passwords

User passwords can sometimes become the weakest link in the security of a given system. This is due to some users choosing weak passwords for their accounts (and the more of them that have access to it the greater the chances of this happening). Even if you established checks with the cracklib PAM module and password limits as described in 第 4.11.1 節「ユーザ認証: PAM」 users will still be able to use weak passwords. Since user access might include remote shell access (over ssh, hopefully) it's important to make password guessing as hard as possible for the remote attackers, especially if they were somehow able to collect important information such as usernames or even the passwd and shadow files themselves.
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 having access to the hashed passwords (the /etc/shadow file).
An administrator can use john or crack (both are brute force password crackers) together with an appropriate wordlist to check users' passwords and take appropriate action when a weak password is detected. You can search for Debian GNU packages that contain word lists using apt-cache search wordlist, or visit the classic Internet wordlist sites such as ftp://ftp.ox.ac.uk/pub/wordlists or ftp://ftp.cerias.purdue.edu/pub/dict.

4.11.22. Logging off idle users

Idle users are usually a security problem, a user might be idle maybe because he's out to lunch or because a remote connection hung and was not re-established. For whatever the reason, idle users might lead to a compromise:
  • because the user's console might be unlocked and can be accessed by an intruder.
  • 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 telnet).
Some remote systems have even been compromised through an idle (and detached) screen.
Automatic disconnection of idle users is usually a part of the local security policy that must be enforced. There are several ways to do this:
  • If bash is the user shell, a system administrator can set a default TMOUT value (see bash(1)) which will make the shell automatically log off remote idle users. Note that it must be set with the -o option or users will be able to change (or unset) it.
  • Install timeoutd and configure /etc/timeouts according to your local security policy. The daemon will watch for idle users and time out their shells accordingly.
  • Install autolog and configure it to remove idle users.
The timeoutd or autolog daemons are the preferred method since, after all, users can change their default shell or can, after running their default shell, switch to another (uncontrolled) shell.


[16] In old Debian releases the configuration of the modules was defined directly in /etc/pam.d/passwd.
[17] The minlen option is not entirely straightforward and is not exactly the number of characters in the password. A tradeoff can be defined between complexity and length by adjusting the "credit" parameters of different character classes. For more information read the pam_cracklib(8) manpage.
[18] The default content of this file provides information about the operating system and version run by the system, which you might not want to provide to anonymous users.
[19] libpam-chroot has not been yet thoroughly tested, it does work for login but it might not be easy to set up the environment for other programs
[20] Setting HISTSIZE to a very large number can cause issues under some shells since the history is kept in memory for every user session. You might be safer if you set this to a high-enough value and backup user's history files (if you need all of the user's history for some reason)
[21] Without the append-only flag users would be able to empty the contents of the history file running > .bash_history
[22] As defined in /etc/adduser.conf (USERGROUPS=yes). You can change this behaviour if you set this value to no, although it is not recommended
[23] Chpasswd cannot handle MD5 password generation so it needs to be given the password in encrypted form before using it, with the
-e
option.