ブートプロンプトに 「<name-of-your-bootimage> init=/bin/sh」と 入力することによってだれでも簡単に root のシェルを得てあなたのパスワードを 変更することができます。パスワードを変更してシステムを再起動すれば、 その人は root で無制限にアクセスでき、そのシステムでしたいことが何でも できます。これが行われたあとではあなたは自分のシステムに root でアクセス できないでしょう。というのもあなたには root のパスワードがわからないからです。
これがおこらないようにするには、ブートローダにパスワードを設定するべきです。 グローバルパスワードか、あるイメージに対するパスワードかを選択できます。
LILO では設定ファイル /etc/lilo.conf
を
編集して以下の例のように「password」と
「restricted」の行を加える必要があります。
image=/boot/2.2.14-vmlinuz label=Linux read-only password=hackme restricted
これを行ったら、lilo をふたたび実行してください。「restricted」の行をはぶくと
LILO に引数が渡されたかどうかにかかわらず lilo がパスワードを要求するように
なります。/etc/lilo.conf
のデフォルトのパーミッションでは root
に読み書きの 許可があり、lilo.conf のグループ、つまり root
が読みとりだけ行うことが できます。
LILO のかわりに GRUB を使っていれば、/boot/grub/menu.lst
を
編集して次の 2 行を先頭に加えてください。(もちろん「hackme」はお望みの
パスワードに置きかえてください。) こうするとユーザがブートアイテムを変更
できなくなります。「timeout 3」は grub がデフォルトのイメージをブートする
までの待ち時間を 3 秒に指定します。
timeout 3 password hackme
パスワードの完全性をさらに強化するためには、パスワードを暗号化された形で 保存することができます。grub-md5-crypt というユーティリティは grub の 暗号化パスワードアルゴリズム (md5) と互換性のあるハッシュされたパスワードを 生成します。grub で md5 形式のパスワードを使うことを指定するには、以下の ディレクティブを使ってください:
timeout 3 password --md5 $1$bw0ez$tljnxxKLfMzmnDVaQWgjP0
grub に md5 認証手続きを行うよう指示するために --md5 が追加されています。 与えられているパスワードは hackme の md5 で暗号化されたパスワードです。 平文バージョンを選ぶのより md5 パスワードを使うほうがよりよいです。 grub のパスワードについては grub-doc パッケージにより多くの情報があります。
Linux 2.4 カーネルは cramfs ファイルシステムをロードした直後に提示される、 ブート時に root のシェルにアクセスする方法を提供します。管理者が root 権限を持つ実行可能なシェルに入ることを可能にするメッセージが表示されます。 このシェルは自動検出が失敗したときにモジュールを手動でロードするのに 使えます。この動作は initrd の linuxrc のデフォルトの動作です。以下の メッセージが表示されます:
Press ENTER to obtain a shell (waits 5 seconds)
この動作をやめさせるには /etc/mkinitrd/mkinitrd.conf
を変更して
こう設定する必要があります:
# DELAY The number of seconds the linuxrc script should wait to # allow the user to interrupt it before the system is brought up DELAY=0
そして ramdisk イメージを再生成します。これはたとえばこのようにして行えます:
# cd /boot # mkinitrd -o initrd.img-2.4.18-k7 /lib/modules/2.4.18-k7
あるいは (推奨):
# dpkg-reconfigure kernel-image-2.4.x-yz
Debian 3.0 woody ではユーザが 2.4 カーネルを (flavors を選んで)
インストールできますが、しかしデフォルトのカーネルは (カーネル 2.2 が
移植されていないいくつかのアーキテクチャをのぞいて) 2.2 であることに
注意してください。これをバグと考えるなら、バグ報告の前に Bug 145244
をごらんください。
バージョン 2.2 より前の Debian でのデフォルトの MBR はふつうのマスター ブートレコードとして働かず、システムに簡単に侵入するための方法を残しています。
このふるまいは次のように入力することで変更できます:
lilo -b /dev/hda
すると LILO が MBR に置かれます。これは lilo.conf に「boot=/dev/hda」を 加えることによっても行うことができます。MBR プロンプトを完全に停止する ほかの解決策もあります:
install-mbr -i n /dev/hda
一方で、ほどんどの人が知らないこの「裏口」は何らかの理由ににより インストールで深刻な問題が起きたときにあなたを救うかもしれません。
FIXME これが 2.2 で本当に正しいのか調べる。それともこれは 2.1 なのか? INFO: Debian 2.2 のブートディスクは mbr をインストール「しません」。 LILO だけです。
セキュリティポリシーによっては管理者がコンソールから自分のユーザおよび
パスワードでシステムにログインして、それから (su
か
sudo
で) スーパーユーザになることを強制したいかもしれません。
Debian ではこのポリシーは /etc/login.defs
ファイル または PAM
を使うときは /etc/securetty
を編集することによって 実施できます。
login.defs
では、root でのログインが許可されている
ファイルまたは端末のリストを定義する CONSOLE 変数を編集します。
securetty
では、root でのアクセスが許可される端末を
追加したり削除したりします。
PAM を使うときはある時刻でのユーザやグループの制限を含むログイン過程の 変更は
/etc/pam.d/login
で設定できます。停止できる 興味深い機能は空の
(空白の) パスワードでログインできる機能です。 この機能は次の行から
nullok を削除することによって制限できます:
auth required pam_unix.so nullok
ext2 パーティションをマウントするとき、マウントの呼びだしまたは
/etc/fstab
に適用できる追加のオプションがいくつかあります。
たとえば、/tmp
についての私の fstab の行は:
/dev/hda7 /tmp ext2 defaults,nosuid,noexec,nodev 0 2
オプションの項目にちがいがあるのがわかるでしょう。nosuid オプションは setuid と setgid ビットを完全に無視します。noexec はその マウントポイントでのどんなプログラムの実行も禁止します。そして nodev はデバイスを無視します。これはよさそうですが、しかしこれは
noexecオプションはバイナリが直接実行されるのを防ぎますが、簡単に 回避されます:
alex@joker:/tmp# mount | grep tmp /dev/hda7 on /tmp type ext2 (rw,noexec,nosuid,nodev) alex@joker:/tmp# ./date bash: ./date: Permission denied alex@joker:/tmp# /lib/ld-linux.so.2 ./date Sun Dec 3 17:49:23 CET 2000
しかし、多くの script kiddie は /tmp
にファイルを
作って実行しようとする 攻撃を行います。script kiddie
に知識がなければ、この落とし穴に落ちるでしょう。 言いかえれば、たとえば偶然
/tmp
を PATH に加えてしまったとき、 ユーザが だまされて
/tmp
にあるトロイの木馬化されたバイナリを 実行してしまうことが
ありえなくなります。
/tmp
が実行可能であることに依存するスクリプトが
あるかもしれないことにも 注意してください。特筆するべきは Debconf
にこれに関する問題がある (あった?) ということです。くわしくは Bug 116448
をごらんください。
以下はより完全な例です。しかし、注意があります: /var
は noexec に
設定できますが、Smartlist などのソフトウェアはそのプログラムを /var に
保存します。これは nosuid オプションにもあてはまります。
/dev/sda6 /usr ext2 defaults,ro,nodev 0 2 /dev/sda12 /usr/share ext2 defaults,ro,nodev,nosuid 0 2 /dev/sda7 /var ext2 defaults,nodev,usrquota,grpquota 0 2 /dev/sda8 /tmp ext2 defaults,nodev,nosuid,noexec,usrquota,grpquota 0 2 /dev/sda9 /var/tmp ext2 defaults,nodev,nosuid,noexec,usrquota,grpquota 0 2 /dev/sda10 /var/log ext2 defaults,nodev,nosuid,noexec 0 2 /dev/sda11 /var/account ext2 defaults,nodev,nosuid,noexec 0 2 /dev/sda13 /home ext2 rw,nosuid,nodev,exec,auto,nouser,async,usrquota,grpquota 0 2 /dev/fd0 /mnt/fd0 ext2 defaults,users,nodev,nosuid,noexec 0 0 /dev/fd0 /mnt/floppy vfat defaults,users,nodev.nosuid,noexec 0 0 /dev/hda /mnt/cdrom iso9660 ro,users,nodev.nosuid,noexec 0 0
/tmp
を noexec に設定して新しいソフトウェアを実行したいときは
注意してください。なぜなら、ソフトウェアの中には /tmp
を
インストールに使うものがあるかもしれないからです。適切に
APT::ExtractTemplates::TempDir
(apt-extracttemplates(1)
をごらんください)
が設定されていなければ、apt は そのようなプログラムのひとつです (http://bugs.debian.org/116448
を ごらんください)。/etc/apt/apt.conf
中のこの変数を
/tmp
以外の実行権限がついた他のディレクトリに設定することが
できます。
noexec については、これはそれほどセキュリティを提供するわけではないことに 注意してください。これを考えてください:
$ cp /bin/date /tmp $ /tmp/date (does not execute due to noexec) $/lib/ld-linux.so.2 /tmp/date (works since date is not executed directly)
/usr
を読みとり専用に設定するとあなたの Debian GNU/Linux
システムに新パッケージをインストールすることができなくなります。まずそれを
読み書き両用で再マウントし、パッケージをインストールして読みとり専用で
再マウントする必要があるでしょう。apt の (Debian 3.0 「woody」にある) 最新版は
パッケージのインストール前後にコマンドを実行するように設定できます。
したがってこれを適切に設定したくなるかもしれません。
これを行うには /etc/apt/apt.conf
を変更して以下を
追加してください:
DPkg { Pre-Invoke { "mount /usr -o remount,rw" }; Post-Invoke { "mount /usr -o remount,ro" }; };
Post-Invoke が 「/usr busy」エラーメッセージとともに失敗するかもしれない ことに注意してください。これは主に更新されるファイルを更新中に使っている ときにおこります。いらいらしますが大した問題ではありません。そのファイルが 使われていないようにして Post-Invoke を手動で実行してください。
パッケージにあるセキュリティ関連の新しいバグが明らかになるとすぐに、 Debian
のメンテナと上流開発者はふつうそれを数日あるいは数時間以内に
修正します。バグが修正されると、新パッケージが http://security.debian.org
で提供されます。sources.list に次の
行を加えるとシステムを更新するたびにセキュリティ関連の更新を自動的に 行えます。
deb http://security.debian.org/debian-security stable/updates main contrib non-free
強力な暗号を輸入したり使用したりすることを禁止する国には住んでいない人たちは 次の行も加えるべきです:
deb http://security.debian.org/debian-non-US stable/non-US main contrib non-free
もし望むなら、apt に deb-src の行も加えることができます。くわしくは
apt(8)
をごらんください。
セキュリティ上の更新はひんぱんに行うべきです。攻撃の大部分はパッチを
あてていない既知の脆弱性によるものです。これは http://www.cs.umd.edu/~waa/vulnerability.html
name="paper by Bill Arbaugh"> (presented on the 2001 IEEE
Symposium on Security and Privacy) で説明されている通りです。
FIXME: これを cron job で自動的に行えるように、パッケージの署名が どうやって行われているかについての情報を加える。(大きな警告: DNS のまね)
PAM (Pluggable Authentication Modules) は
アプリケーションがユーザをどうやって認証するかをシステム管理者が
選ぶことを可能にします。アプリケーションが PAM をサポートするように
コンパイルされていないと PAM は何もできないことに注意してください。 Debian 2.2
で出荷されているアプリケーションの大半はこのサポートが組みこまれて
います。さらに Debian は 2.2 以前には PAM のサポートがありませんでした。
各アプリケーションに対して /etc/pam.d/
の中に設定ファイルが
あります。これを使って動作を変えることができます。以下の説明は完全には
ほど遠いものです。くわしくは The
Linux-PAM System Administrator's Guide
(primary PAM distribution
site
にあります) をごらんください。
PAM はユーザに知られることなくいくつかの認証の段階を一度に行うことを 可能にします。Berkeley データベースと通常の passwd ファイルで認証することが できます。両方で正しく認証された場合のみユーザはログインします。PAM で きつく制限することもできますし、システムを非常に広く開放することもできます。 だから注意してください。典型的な設定行にはコントロールフィールドが 2 番目の要素としてあります。 一般的にこれは「requisite」に設定するべきです。これはモジュールがひとつでも 失敗すればログイン失敗を返します。
最初に行いたいことは PAM アプリケーションに MD5 サポートを加えることです。
なぜならこれは辞書攻撃を防ぐのを助けるからです。以下の 2 行を
/etc/pam.d/
の 中の login や ssh
のような、マシンへのアクセスを認める すべてのファイルに加えるべきです。
# 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 required pam_unix.so use_authtok nullok md5
それで、この呪文は何をするのでしょうか? 最初の行は cracklib PAM モジュールを ロードします。これはパスワードの強度のチェックを行えるようにし、 新パスワードは長さが 12 文字以上でかつ古いパスワードとすくなくとも 3 文字以上 異なっていることを要求します。2 番目の行は MD5 パスワードの標準的な認証 モジュールを導入して長さ 0 文字のパスワードを許可します。use_authtok ディレクティブはパスワードを前のモジュールに渡すのに必要です。
root ユーザはローカル端末からしかログインできないようにするには、
/etc/pam.d/login
で以下の行を有効にするべきです。
auth requisite pam_securetty.so
そして root ユーザがシステムにログインできる端末を
/etc/security/access.conf
に加えるべきです。最後だからといって
重要でないというわけではありませんが、もしユーザ制限を設定したいなら
以下の行を有効にするべきです。
session required pam_limits.so
これはユーザが使えるシステム資源を制限します。以下にある limits.conf ファイル, 第 4.7.2 節 をごらんください。 たとえば、(あるユーザグループの、またはシステム全体の) 同時に行える ログインの個数、プロセスの個数、メモリの大きさなどを制限できます。
ここで /etc/pam.d/passwd
を編集して最初の行を変更しましょう。 MD5
パスワードを使うために「md5」オプションを加え、パスワードの長さの 最小値を 4
から 6 (あるいはそれ以上) に変更し、もし望むなら長さの最大値を
設定するべきです。するとその行はこのようになります。
password required pam_unix.so nullok obscure min=6 max=11 md5
あなたのシステム上である人たちだけが 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
最後だからといって重要でないというわけではありませんが、
/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 をサポートするすべてのアプリケーションに対しよい デフォルトの設定を提供します (デフォルトではアクセスは拒否されます)。
このファイルは本当に真剣に調べるべきです。ここでユーザの資源の制限を
定義することができます。もし PAM を使うならば、 /etc/limits.conf
は無視されるので、かわりに /etc/security/limits.conf
を使うべきです。
FIXME: ここでよい limits.conf をしあげる
次の段階はユーザログインに際しての基本的な設定や行動を編集することです。
FAIL_DELAY 10
力まかせでログインするのに端末を使うのをむずかしくするためこの変数は 大きな値に設定するべきです。もしまちがったパスワードが入力されると、 攻撃者 (あるいは一般ユーザ!) は次のログインプロンプトを受けるのに 10 秒 待たなければなりません。パスワードをためしているときにはこれは非常に時間を 消費するでしょう。たとえば mingetty などの、getty 以外のプログラムを 使用しているときにはこの設定は役に立たないという事実に注意してください。
FAILLOG_ENAB yes
この変数が設定されていると、ログインの失敗がログに記録されます。力まかせの 攻撃をためしている人をつかまえるために失敗を追跡することは重要です。
LOG_UNKFAIL_ENAB yes
変数「FAILLOG_ENAB」を yes に設定したら、この変数も yes に設定するべきです。 これはログインが失敗したとき未知のユーザ名を記録します。これを行うなら、 ログが適切なパーミッション (たとえば 640 で、adm などの適切なグループ設定を 行っているもの) を持っているようにしてください。なぜならユーザはしばしば まちがってパスワードをユーザ名として入力しますし、あなたはそれを他の人に 見られたくないからです。
SYSLOG_SU_ENAB yes
これは su の試みを syslog に記録するようにします。重要なマシン上では 非常に大切ですが、これはプライバシー問題をひきおこすかもしれないことに 注意してください。
SYSLOG_SG_ENAB yes
SYSLOG_SU_ENAB と同じですが sg
プログラムに適用されます。
MD5_CRYPT_ENAB yes
上で述べたように、MD5 sum のパスワードは辞書攻撃の問題を非常に減らします。 なぜならより長いパスワードを使えるからです。 もし slink を使っているなら、このオプションを有効にする前に MD5 についての 文書を読んでください。そうでないなら、これは PAM で設定されています。
PASS_MAX_LEN 50
もし PAM の設定で MD5 パスワードが有効になっているなら、この変数をそこで 用いたのと同じ値に設定するべきです。
このファイルは ftp を使ってホストにログインすることが許可されていない ユーザのリストを含みます。ftp を本当に許可したいときだけこのファイルを 使ってください (一般に ftp は推奨されていません。なぜならこれは平文の パスワードを使うからです)。あなたのデーモンが PAM をサポートしているなら、 特定のサービスをユーザに許可したり拒否したりするのにそれを使うことも できます。
パッケージをインストールするとかユーザを追加するとかのためにあなたの
システムで本当にスーパーユーザになる必要があるなら、身分を変更するために
su
コマンドを使うことができます。root ユーザでのログインを
避けてかわりに su を使うべきです。実際、最良の解決法は su を削除して
sudo
に移行することです。なぜならこれは su より多くの機能を
持つからです。しかし、su は他の多くの Unixes でより一般的です。
sudo
はユーザが root を含む他のユーザの身分で定義されたコマンドを
実行することを可能にします。もしユーザが /etc/sudoers
に
追加されていて、認証が正しく行われれば、/etc/sudoers
で定義された
コマンドを実行することができます。パスワードをまちがえたり許可のない
プログラムを実行しようとしたりといった違反は記録され root にメールで
送られます。
サービス (pop3 メールサービスや ftp) を提供するためにローカルシステムに ユーザを作成する必要があると思うことがあるかもしれません。そうする前に、 Debian GNU/Linux での PAM の実装は libpam パッケージによって提供される いろいろな外部のディレクトリサービス (radius や ldap など) でユーザを 認証することができることを思い出してください。
ユーザを作成する必要があって、リモートからシステムにアクセスできるなら、
そのユーザがシステムにログインできるかもしれないことを考慮してください。
そのユーザに空の (/dev/null
) シェル (/etc/shells
中に記載されている必要があります) を与えることによってこれを修正できます。
ユーザがシステムにアクセスできるようにしたいがその行動を制限したいならば、
/bin/rbash
を使うことができます。これは bash で -r
オプション (RESTRICTED SHELL bash(1)
を ごらんください)
を追加するのと等価です。制限されたシェルでも、対話的な プログラム
(これはサブシェルの実行を許すかもしれません) にアクセスする
ユーザはこの制限をかいくぐることができるかもしれないことに注意してください。
Debian は現時点では pam_chroot
モジュールを提供していません
(将来は提供されるかもしれません)。かわりにリモートログインを提供する サービス
(ssh や telnet) を chroot してください。
ユーザがシステムにアクセスできる時刻を制限したいなら
/etc/security/access.conf
を必要にあわぜて設定する必要が
あるかもしれません。
Debian の sshd ではユーザの移動をサーバを通して制限することはできません。
なぜなら商用のプログラム (sshd2) が持っている Chroot 機能 (「ChrootGroups」
または 「ChrootUsers」を使います。sshd2_config(5)
を
ごらんください) がないからです。しかし、これを可能にするパッチがあります。
このパッチは Bug report
139047
または http://www.cag.lcs.mit.edu/~raoul/
から入手できます (そして 将来は OpenSSH
パッケージにこれが適用されるかもしれません)。Emmanuel Lacour
さんはこの機能つきの ssh パッケージを http://debian.home-dn.net/woody/ssh/
に置いていますが、自分で
コンパイルすることが推奨されています。必要なすべての手続きの説明が http://mail.incredimail.com/howto/openssh/
にあります (これは RedHat 7.2 について述べていますが、ほどんどすべてが Debian
にも 適用可能です)。このパッチを適用したらあとは /etc/passwd
を
修正してユーザのホームのパスを変更するだけです (特別な /./
トークンを使います):
joeuser:x:1099:1099:Joe Random User:/home/joe/./:/bin/bash
これはリモートシェルアクセスおよび ssh チャンネル経由のリモートコピーの 両方を制限します。
必要なバイナリおよびライブラリがすべてユーザの chroot パスの中にあるように してください。これらのファイルはユーザに (chroot の檻から脱出するなどの 目的で) 改ざんされないように root によって所有されるべきです。たとえば 以下が含まるでしょう:
./bin: total 660 drwxr-xr-x 2 root root 4096 Mar 18 13:36 . drwxr-xr-x 8 guest guest 4096 Mar 15 16:53 .. -r-xr-xr-x 1 root root 531160 Feb 6 22:36 bash -r-xr-xr-x 1 root root 43916 Nov 29 13:19 ls -r-xr-xr-x 1 root root 16684 Nov 29 13:19 mkdir -rwxr-xr-x 1 root root 23960 Mar 18 13:36 more -r-xr-xr-x 1 root root 9916 Jul 26 2001 pwd -r-xr-xr-x 1 root root 24780 Nov 29 13:19 rm lrwxrwxrwx 1 root root 4 Mar 30 16:29 sh -> bash ./etc: total 24 drwxr-xr-x 2 root root 4096 Mar 15 16:13 . drwxr-xr-x 8 guest guest 4096 Mar 15 16:53 .. -rw-r--r-- 1 root root 54 Mar 15 13:23 group -rw-r--r-- 1 root root 428 Mar 15 15:56 hosts -rw-r--r-- 1 root root 44 Mar 15 15:53 passwd -rw-r--r-- 1 root root 52 Mar 15 13:23 shells ./lib: total 1848 drwxr-xr-x 2 root root 4096 Mar 18 13:37 . drwxr-xr-x 8 guest guest 4096 Mar 15 16:53 .. -rwxr-xr-x 1 root root 92511 Mar 15 12:49 ld-linux.so.2 -rwxr-xr-x 1 root root 1170812 Mar 15 12:49 libc.so.6 -rw-r--r-- 1 root root 20900 Mar 15 13:01 libcrypt.so.1 -rw-r--r-- 1 root root 9436 Mar 15 12:49 libdl.so.2 -rw-r--r-- 1 root root 248132 Mar 15 12:48 libncurses.so.5 -rw-r--r-- 1 root root 71332 Mar 15 13:00 libnsl.so.1 -rw-r--r-- 1 root root 34144 Mar 15 16:10 libnss_files.so.2 -rw-r--r-- 1 root root 29420 Mar 15 12:57 libpam.so.0 -rw-r--r-- 1 root root 105498 Mar 15 12:51 libpthread.so.0 -rw-r--r-- 1 root root 25596 Mar 15 12:51 librt.so.1 -rw-r--r-- 1 root root 7760 Mar 15 12:59 libutil.so.1 -rw-r--r-- 1 root root 24328 Mar 15 12:57 libwrap.so.0 ./usr: total 16 drwxr-xr-x 4 root root 4096 Mar 15 13:00 . drwxr-xr-x 8 guest guest 4096 Mar 15 16:53 .. drwxr-xr-x 2 root root 4096 Mar 15 15:55 bin drwxr-xr-x 2 root root 4096 Mar 15 15:37 lib ./usr/bin: total 340 drwxr-xr-x 2 root root 4096 Mar 15 15:55 . drwxr-xr-x 4 root root 4096 Mar 15 13:00 .. -rwxr-xr-x 1 root root 10332 Mar 15 15:55 env -rwxr-xr-x 1 root root 13052 Mar 15 13:13 id -r-xr-xr-x 1 root root 25432 Mar 15 12:40 scp -rwxr-xr-x 1 root root 43768 Mar 15 15:15 sftp -r-sr-xr-x 1 root root 218456 Mar 15 12:40 ssh -rwxr-xr-x 1 root root 9692 Mar 15 13:17 tty ./usr/lib: total 852 drwxr-xr-x 2 root root 4096 Mar 15 15:37 . drwxr-xr-x 4 root root 4096 Mar 15 13:00 .. -rw-r--r-- 1 root root 771088 Mar 15 13:01 libcrypto.so.0.9.6 -rw-r--r-- 1 root root 54548 Mar 15 13:00 libz.so.1 -rwxr-xr-x 1 root root 23096 Mar 15 15:37 sftp-server
もしあなたがパラノイドならシェルから監査機能を削除できないように環境を 設定する
.profile
をユーザに追加したいかもしれません。 コマンドは
$HISTFILE にダンプされます。このような .profile
は以下のように設定できます:
HISTFILE=/home/_user_/.bash_history HISTSIZE=100000000000000000 HISTFILESIZE=10000000000000000 set -o HISTFILE set -o HISTSIZE set -o HISTFILESIZE export HISTFILE HISTSIZE HISTFILESIZE
注: -o 属性は bash において変数を読みとり専用にします。
これがうまいくいくためにはユーザが .profile
または
.bash_history
を変更できてはいけませんが、 .profile
を読むことおよび .bash_history
に
書きこむことが可能でなければなりません。これらのファイルおよび
これらのファイルがあるディレクトリを他のユーザ (root) が所有するようにして、
そのユーザのグループに history ファイルへの書きこみ許可を与えることによって
これを簡単に行えます。他の選択肢は chattr
プログラムを使う
ことです。
もしあなたが本当にパラノイドですべてのユーザのコマンドを監査したいなら、 bash
のソースコードを入手し、それを編集してユーザが打ちこんだものすべてを
他のファイルに送るようにすることができます。または ttysnoop
が新しい tty すべてを監視して出力をファイルにダンプするようにするように
しましょう。他の役に立つプログラムは Snoopy
です。これはユーザ透過性を持つプログラムで、execve() システムコールの
ラッパーを提供するライブラリとして働きます。実行されるどのコマンドも
authpriv facility (ふつうは /var/log/auth.log
に
保存されます)で syslogd を使って記録されます。 !-- FIXME: Debian package for
snoopy??? -->
この目的に script
コマンドを使うことはできないことに注意して
ください。なぜなら script
は (たとえ /etc/shells
に
追加しても) シェルとしては働かないからです。
前の例はユーザ監査を設定する単純な例です。これは複雑なシステムでは役に
立たないかもしれません。もしあなたのシステムがそうなら、アカウント
ユーティリティである acct
パッケージを検討する必要が
あります。これはシステム中のユーザまたはプロセスが実行するすべてのコマンドを
ディスクスペースとひきかえに記録します。
アカウンティングを有効にすると、プロセスやユーザのすべての情報は
/var/account/
以下に、特に pacct
中に保存されます。
acct
パッケージにはこの情報を解析する道具 (sa
と
ac
) を含みます。
ユーザがふだん何をしているのか見たいなら、そのユーザが接続して
いるときに wtmp
データベースを使うことができます。これは
すべてのログイン情報を含みます。このファイルはいくつかのユーティリティに
よって処理できますが、中でも sac
は各ユーザごとにシステムに
いつログインしているか表示することができます。
アカウンティングを有効にしている場合は、ユーザがシステムにいつアクセスし 何を実行しているか知るためにそれによって提供される道具を使うことができます。
TCP wrapper は本当のパケットフィルタが利用できずアクセス制御が必要だったときに
開発されました。TCP wrapper はサービスをあるホストまたはあるドメインに
許可したり拒否したりし、デフォルトの許可または拒否の規則を定義することを
可能にします。よりくわしく知りたければ hosts_access(5)
をごらんください。
Debian でインストールされるサービスの多くは:
tcpd
) を通して起動されるか、
/etc/inetd.conf
で設定されるサービスがあります。これには
telnet、ftp、netbios、swat そして finger が含まれます (この設定ファイルが まず
/usr/sbin/tcpd
を実行するのがわかるでしょう)。一方で、 サービスが
inetd
スーパーデーモンを通じて起動されるのでなくても、 tcp wrapper
規則のサポートが組みこまれているとその規則に従います。tcp wrapper
が組みこまれている、Debian の サービスは ssh、portmap、in.talk、
rpc.statd、rpc.mountd、gdm、oaf (GNOME 起動デーモン)、nessus その他
いろいろです。
tcpchk
を走らせるときはこのことを考慮してください。wrapper
ライブラリにリンクされているサービスを host.deny
や
hosts.allow
ファイルに追加することができますが、
tcpchk
はこれらのサービスを発見できないと警告するでしょう。
というのも tcpchk
は /etc/inetd.conf
を見て
これらのサービスをさがすからです (マニュアルページはここでは完全に正確と
いうわけではありません)。
ここで、小さなトリックがあります。たぶん利用可能なもののうち最小の侵入検知 システムでしょう。一般に、最初の抵抗線としてよいファイアウォールポリシーを、 2 番目の抵抗線として TCP wrapper を持つべきです。小さなトリックとは 拒否されているサービスが wrapper を呼ぶたびに root にメールを送る SPAWN [1] コマンドを /etc/hosts.deny に設定することです。
ALL: ALL: SPAWN ( \ echo -e "\n\ TCP Wrappers\: Connection refused\n\ By\: $(uname -n)\n\ Process\: %d (pid %p)\n\ User\: %u\n\ Host\: %c\n\ Date\: $(date)\n\ " | /usr/bin/mail -s "Connection to %d blocked" root) &
注意: 上記の例は短時間に大量の接続を行うことによって簡単に DoS されます。大量の電子メールが送られるということはわずか数パケットを 送ることによって大量のファイル入出力を発生させられるということです。
ログや警告がどう扱われるかは安全なシステムでは重要な問題です。システムが 完璧に設定されていて、たとえば 99% 安全だとしても、これを理解するのは 簡単です。もし残りの 1% が発生したとき、まずそれを検知し、次に警告を出すような セキュリティ対策があるべき場所になければ、そのシステムは全く安全でない ことになります。
Debian GNU/Linux はログ解析を行う道具をいくつか提供します。最も注目するべきは
logcheck
です。しかし、
ログの解析についてはここで扱いきれないことがらが多くあります。 Couterpane's Log Analysis
Resources
はこの情報についての よい供給源です。
Debian ではシステムの機能に応じて適切なファイルにメッセージを記録する 標準的な
syslog の設定が (/etc/syslog.conf で) 行われています。これらに
詳しくなるべきです。ファイル syslog.conf
を見るか、そうしないなら
文書を見てください。もし安全なシステムを維持したいならばメッセージを
見のがさないようそれがどこに送られるかについて知っておくべきです。
たとえば、メッセージをコンソールにも送ることは多くの実用レベルのシステムで 役立つ興味深い設定です。しかしそのような多くのシステムではログホスト (すなわち、他のすべてのシステムからログを受けとるマシン) として働く 新しいマシンを追加することも重要です。
root へのメールも検討するべきです。(snort
のような)
多くのセキュリティ制御ソフトは警告を root のメールボックスに送ります。
このメールボックスはふつうシステムで最初に作られたユーザを指しています
(/etc/aliases
を調べてください)。 root
のメールをちゃんと読まれる場所 (ローカルでもリモートでも)
に送るように注意してください。
他にも役割のあるアカウントやエイリアスがシステムにはあります。小さな システムでは、これらのエイリアス全てが root アカウントをさすようにし、 root へのメールがシステム管理者の個人メールボックスに転送されるように するのがたぶん最も簡単でしょう。
FIXME: Debian システムがセキュリティ問題に関する SNMP トラップを送ったり
受けとったりする方法を述べるのは興味深いだろう (jfs)。
snmptraglogd
、snmp
そして snmpd
参照。
ログホストは syslog のデータをリモートからネットワーク経由で集めるホストです。
もしあなたのマシンのひとつがクラックされたら、ログホストもクラックしない
かぎり侵入者は痕跡を隠すことができません。したがって、ログホストは特に安全で
ある必要があります。マシンをログホストにするのは簡単です。syslogd を 「syslogd
-r」で開始するだけで新しいログホストのできあがりです。 これを Debian
上で永続的に行うためには、/etc/init.d/sysklogd
を 編集して
SYSLOGD=""
という行を
SYSLOGD="-r"
に変えてください。 次に、他のマシンをログホストにデータを送るように設定します。
/etc/syslog.conf
に以下のような項目を加えます:
facility.level @your_loghost
facility や level のかわりに何を使うべきかは文書を 見てください (これらを文字どおりこのまま入力するべきではありません。) 何もかもリモートで記録したいならば、単に syslog.conf にこう書くだけです:
*.* @your_loghost
ローカルとともにリモートでも記録することが最良の解決策です (攻撃者は
ローカルのログファイルを削除したあとで痕跡を隠したと思うかもしれません)。
よりくわしくは syslog(3)
, syslogd(8)
そして
syslog.conf(5)
をごらんください。
警告がどう使われるかを決めることだけでなく、だれがそれにアクセスできるか、 すなわちログファイルを読んだり (もしリモートのログファイルを使っていないなら) 変更したりできるかを決めるのも重要です。攻撃者が変更したり停止したり できるようなセキュリティ上の警告は侵入の際にはそれほど役に立ちません。
ログファイルの中にはインストール後にパーミッションが完璧ではないものが
あります。最初に /var/log/lastlog
と /var/log/faillog
が一般ユーザに読める必要はありません。 lastlog
ファイルではだれが最近ログインしたかわかります。そして faillog では
失敗したログインの要約を見ることができます。このマニュアルの著者はこの両方を
660 に chmod することを推奨します。ログファイルをすこしながめて、
どのログファイルを UID が 0 でないユーザや「adm」でも「root」でもない
グループが読んだり書きこんだりできるようにするか非常に注意深く決めてください。
apache のユーザが apache のログファイルを所有しているという事実によって apache のログファイルのパーミッションが本当に変になっていることを強調して おきます。ユーザが apache の裏口でシェルを入手したら、簡単にログファイルを 削除することができます。
Debian は 毎日実行される cron job を /etc/cron.daily/standard
で
提供しています。この cron job は setuid の変化を保存する
/usr/sbin/checksecurity
スクリプトを実行します。
このチェックを行うためには /etc/checksecurity.conf
で
CHECKSECURITY_DISABLE="FALSE"
を設定しなければなりません。
これはデフォルトなので、何も変更していなければ、このオプションはすでに
「FALSE」に設定されていることに注意してください。
デフォルトのふるまいではこの情報をスーパーユーザに送りはしませんが、
この変化の毎日の記録を /var/log/setuid.changes
に保存します。
この情報を root に送るために (/etc/checksecurity.conf
中の)
CHECKSECURITY_EMAIL を「root」に設定するべきです。設定についてくわしくは
checksecurity(8)
をごらんください。
chroot
はデーモンやユーザやその他のサービスを制限するための
最も強力な可能性のひとつです。対象のまわりに檻があると考えてください。
対象はここから逃げることができません (ふつうはできませんが、このような
檻がら逃げだすことを可能にする条件はいくつもあります)。もしユーザを信用
しないのであれば、そのユーザのために chroot された環境を作ることができます。
檻の中にライブラリとともに必要な実行ファイルをすべてコピーしなければ
ならないので、これはディスクスペースを大量に消費するかもしれません。
たとえそのユーザが何か悪事をはたらいても、被害の範囲はその檻に限定されます。
このような場合のよい例には /etc/passwd
ではなくかわりに LDAP
または MySQL で認証する場合です。すると ftp デーモンにはバイナリと
もしかしたらいくつかのライブラリだけが必要です。chroot された環境は
非常にセキュリティを向上させるでしょう。もしこの ftp デーモンに新しい攻撃が
発見されても、攻撃者は ftp デーモンのユーザの UID だけしか攻撃できません。
もちろん、他の多くのデーモンにもこの種の設定が役に立つでしょう。
しかし、chroot
はそこで動いているユーザがスーパーユーザなら
破られる可能性があることに注意してください。だから、サービスは非特権ユーザと
して動かす必要があります。環境を制限することによってそのサービスが
アクセスできる、世界中から読める (または実行できる) ファイルを制限して
いることになります。こうしてあなたのシステムにあるローカルのセキュリティ上の
脆弱性を使った、権限の昇進の可能性を制限するわけです。この場合でも、
かしこい攻撃者がこの檻を破る方法が全くないとは言えません。安全だという
評判があるサーバプログラムだけを使うのは安全のための追加の手段としてよいです。
オープンファイルハンドルのような非常に小さなセキュリティホールでも
熟練した攻撃者によってシステムを破るのに使われる可能性があります。
結局、chroot
はセキュリティ関連の道具としてではなく試験用の
道具として設計されたのです。
つけくわえますが、Debian のデフォルトの BIND (インターネットネームサービス) は デフォルトでは chroot されていません。実際、どのデーモンも chroot されて いません。これは woody (3.0) リリースで変わるかもしれません。
chroot 環境を設定するのを助けるソフトも存在します (現時点では Debian には
入っていませんが、将来はパッケージ化されるかもしれません)。たとえば、
makejail
は chroot の檻を短い設定ファイルを使って作ったり
更新したりできます。またこれはデーモンに必要なファイルをすべて推測して
檻の中へインストールしようとします。くわしくは http://www.floc.net/makejail/
をごらんください。 Jailer
は http://www.balabit.hu/downloads/jailer/
で 入手できる似たような道具です。
FIXME: 中身が足りない
カーネルの機能の多くは /proc
ファイルシステムの中に 何かを echo
で入力するか sysctl を使うかすることによって稼働中に変更することができます。
sysctl -A と入力することにより何が設定できてオプションは何なのかを
知ることができます。ここで何かを編集する必要はめったにありませんが、
このようにしてセキュリティを向上させることもできます。
net/ipv4/icmp_echo_ignore_broadcasts = 1
これは「windows エミュレータ」です。なぜならこれが 1 に設定されていれば ブロードキャスト ping に windows のように反応するからです。 それ以外なら何もしません。
net/ipv4/icmp_echo_ignore_all = 0
ファイアウォールで ICMP をブロックしたくないなら、これを有効にしてください。
net/ipv4/tcp_syncookies = 1
これは両刃の剣です。一方でこれは syn flooding からあなたのシステムを 守ります。一方でこれは定義された規格 (RFC) に違反します。このオプションは あなたの側と同じように反対側にも洪水を送り、反対側もビジー状態にするので とても頭が悪いです。もしこのオプションを変更したいのであれば、 /etc/network/options で syncookies=yes を設定することに よってこれを変更することもできます。
/proc/sys/net/ipv4/conf/all/log_martians = 1
あなたのネットワーク上の (まちがった経路のせいで) ありえないアドレスを 持ったパケットが記録されます。
これやその他の役に立つものを設定するための例がこれです。これを
/etc/network/interface-secure
(この名前は例としてあげられて
います) 中のスクリプトに追加し、それを /etc/network/interfaces
からこのように呼び出すべきです:
auto eth0 iface eth0 inet static address xxx.xxx.xxx.xxx netmask 255.255.255.xxx broadcast xxx.xxx.xxx.xxx gateway xxx.xxx.xxx.xxx pre-up /etc/network/interface-secure
# Script-name: /etc/network/interface-secure # Modifies some default behaviour in order to secure against # some TCP/IP spoofing & attacks # # Contributed by Dariusz Puchalak # echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts # broadcast echo protection enabled echo 0 > /proc/sys/net/ipv4/ip_forward # ip forwarding disabled echo 1 > /proc/sys/net/ipv4/tcp_syncookies # TCP syn cookie protection enabled echo 1 >/proc/sys/net/ipv4/conf/all/log_martians # Log packets with impossible addresses # but be careful with this on heavy loaded web servers echo 1 > /proc/sys/net/ipv4/ip_always_defrag # defragging protection always enabled echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses # bad error message protection enabled # now ip spoofing protection for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $f done # and finally some more things: # Disable ICMP Redirect Acceptance for f in /proc/sys/net/ipv4/conf/*/accept_redirects; do echo 0 > $f done for f in /proc/sys/net/ipv4/conf/*/send_redirects; do echo 0 > $f done # Disable Source Routed Packets for f in /proc/sys/net/ipv4/conf/*/accept_source_route; do echo 0 > $f done # Log Spoofed Packets, Source Routed Packets, Redirect Packets for f in /proc/sys/net/ipv4/conf/*/log_martians; do echo 1 > $f done
ローカルシステムかそれの背後にあるシステムを守るために
ファイアウォール機能を使うためには、カーネルにファイアウォール機能を含めて
コンパイルする必要があります。標準の Debian 2.2 カーネル (これも 2.2 です
はパケットフィルタ ipchains
ファイアウォールを提供します。 Debian
3.0 の標準のカーネル (カーネル 2.4) は状態ごとの (stateful)
パケットフィルタ iptables
(netfilter) ファイアウォールを
提供します。古い Debian ディストリビューションは適切なカーネルパッチを
必要とするでしょう (Debian 2.1 はカーネル 2.0.34 を使っています)。
いずれの場合も、Debian によって提供されるカーネル以外のカーネルを使うのは
とても簡単です。Debian システムに簡単にインストールできるコンパイルずみの
カーネルがパッケージとして存在します。kernel-source-X
を
使ってカーネルソースをダウンロードし、make-kpkg
を
使って特製のカーネルパッケージを作ることもできます。
Debian でのファイアウォール構築は ファイアウォール機能を追加する, 第 5.15 節 でよりくわしく 論じられています。
FIXME: もっと内容を
Debian GNU/Linux はセキュリティを向上させる Linux カーネルのパッチを いくつか提供しています。これには以下が含まれます。
lids-2.2.19
パッケージ中)
lcap
パッケージ中)
trustees
パッケージ中)
selinux
パッケージ中。 the developer's website
からも入手できます。)
kernel-patch-2.2.19-harden
lcap
パッケージ中)
kernel-patch-freeswan
パッケージ中)
kernel-patch-int
あるホストから他のホストへファイルを安全な方法でコピーするのは ssh パッケージ中に含まれる「scp」を使うことによって達成できます。これは rcp と 同様に働きますが、完全に暗号化されて働きます。よって悪人には「何を」コピー しているのかさえわかりません。
よい quota ポリシーを持つことは重要です。なぜならそれはユーザがハード ディスクをいっぱいにするのを防ぐからです。
2 種類の異なる quota システムを使うことができます: ユーザ quota とグループ quota です。ご想像のとおり、ユーザ quota はユーザが占めることができる スペースの量を制限し、グループ quota は同じことをグループに対して行います。 quota の大きさを決めるときにはこれに注意してください。
quota システムを設定するときに考えるべき重要な点がいくつかあります:
/home
とともに /tmp
でも。
ユーザが自由に書きこむことができるパーティション (またはディレクトリ) の すべてで quota を有効にするべきです。そういうパーティションやディレクトリを 発見して、有用性とセキュリティを兼ねそなえるような、うまくいく quota の 大きさを計算しましょう。
それで、quota を使いたいわけです。最初にあなたのカーネルで quota サポートが 有効になっているか調べる必要があります。もしそうなっていないなら、カーネルを 再コンパイルする必要があるでしょう。 そのあとで、「quota」パッケージがインストールされているか制御してください。 もしインストールされていないならこれも必要です。
それぞれのファイルシステムで quota を有効にするのは簡単で、ファイル
/etc/fstab
中の defaults という設定を
defaults,usrquota に変更するだけです。グループ quota が必要なら、
usrquota を grpquota
に置きかえてください。両方を使うことも できます。そして quota
を使いたいファイルシステムのルートに空の quota.user および quota.group
というファイルを作成してください (たとえば、 /home
ファイルシステムでは touch /home/quota.user /home/quota.group
とするわけです)。
/etc/init.d/quota stop;/etc/init.d/quota start を行うことによって quota を再起動してください。すると quota が動いて、quota の大きさが 設定できるようになるはずです。
特定のユーザ (たとえば「ref」)の quota を編集することは edquota -u ref で可能です。グループ quota は edquota -g <group> で変更できます。そして必要に応じて ソフト quota およびハード quota、そして (または) inode quota を設定して ください。
quota についてくわしくは quota のマニュアルページや quota mini-howto
(/usr/share/doc/HOWTO/en-html/mini/Quota.html
)をごらんください。
lshell
をすきになるかどうかは人それぞれでしょう。 なぜならこれは
FHS に違反しているからです。pam_limits.so が同じ機能を
提供するかもしれないこと、lshell
が現在 orphaned
であることも
考慮に入れてください。
この 2 種類のコマンドはとても便利ですが、ext2 ファイルシステムでしか 働きません。「lsattr」でファイルの属性を表示させることができます。そして 「chattr」で属性を変更できます。この属性はパーミッションとは異なることに 注意してください。属性はたくさんありますが、セキュリティを向上させるのに 最も重要なものだけがここで言及されています。スーパーユーザだけが設定できる フラグが 2 種類あります。
まず「a」フラグがあります。ファイルにこれが設定されていると、そのファイルは
追加するためだけにしか開けなくなります。これは /var/log/
中のファイルの
いくつかには便利ですが、それらのファイルはログ回転スクリプトによってときどき
移動されることを考えるべきです。
2 番目のフラグは「i」フラグです。これは immutable の略です。ファイルにこれが 設定されていると、それは変更することも削除することも名前を変えることも できなくなり、それへのリンクも作れなくなります。ユーザに設定ファイルを 調べられたくなければこのフラグを設定して読みとり許可を取りのぞくことが できます。さらにこれは侵入者に対してすこしだけセキュリティを向上させます。 なぜなら、クラッカーはファイルを削除できないことによって混乱するかも しれないからです。それにもかかわらず、クラッカーの目が節穴であると 考えるべきではありません。結局、そのクラッカーはあなたのシステムに 侵入したのです。
lsattr と chattr は ext2 ファイルシステムでのみ利用可能なことに 注意してください。
あなたのハードドライブにある /bin/login
は
本当に数か月前にインストールした バイナリと同じですか?
もしそれが入力されたパスワードを隠しファイルに
保存したり平文でインターネットじゅうにメールで送る、ハックされたバージョンなら
どうでしょうか?
保護のためのただひとつの方法はそのファイルの実際の md5sum と古い md5sum を
比較して毎時間 (または毎日、または毎月) (私は毎日がすきです) ファイルを
調べることです。異なる 2 個のファイルが同じ md5sum を持つことはありえません
(MD5 ダイジェストは 128 ビットです。よって 2 個の異なるファイルが同じ md5sum
を持つ確率はおよそ 3.4e3803 にひとつです)。よって、 だれかがそのマシンで md5sum
を作るアルゴリズムをハックしたのでないかぎり、
あなたは安全な場所にいることになります。これは、まあ、とても困難で、まず
ありえないでしょう。このバイナリの監査は非常に重要だと
本当に考えるべきです。なぜならこれはバイナリへの変更を認識する簡単な
方法だからです。これに使われる一般的な道具は sXid
、
AIDE
(Advanced Intrusion Detection
Environment)、TripWire
(non-freeです。新バージョンは GPL
になる予定です)、 integrit
そして samhain
です。
debsums をインストールすることもすべてのファイルの md5sum を Debian パッケージアーカイブで使われる md5sum と比較することによって ファイルシステムの完全性を調べるのに役立ちます。しかし注意してください、 このファイルは簡単に変更できます。
さらに locate
を slocate
で置きかえる
こともできます。slocate はセキュリティを向上させた GNU locate です。 slocate
を使うと、ユーザは自分がアクセスできるファイルだけしか見ることが
できず、システム上の任意のファイルやディレクトリを除外できます。
Debian は 毎日実行される cron job を /etc/cron.daily/standard
で
提供しています。この cron job は setuid の変化を保存する
/usr/sbin/checksecurity
スクリプトを実行します。
このチェックを行うためには /etc/checksecurity.conf
で
CHECKSECURITY_DISABLE="FALSE"
を設定しなければなりません。
これはデフォルトなので、何も変更していなければ、このオプションはすでに
「FALSE」に設定されていることに注意してください。
デフォルトのふるまいではこの情報をスーパーユーザに送りはしませんが、
この変化の毎日の記録を /var/log/setuid.changes
に保存します。
この情報を root に送るために (/etc/checksecurity.conf
中の)
CHECKSECURITY_EMAIL を「root」に設定するべきです。設定についてくわしくは
checksecurity(8)
をごらんください。
私のようにコンソールが好きな人にとっては SVGAlib はとてもよいですが、以前に
これは非常に危険であると何回か証明されています。zgv
に対する
攻撃が公表されましたし、root になるのは非常に簡単だったのです。可能ならば
SVGAlib プログラムを使うのはいつも避けるべきです。
Debian セキュリティマニュアル
v2.4 Tue, 30 Apr 2002 15:41:13 +0200 (翻訳: Thu, 6 Jun 2002)jfs@computer.org
oohara@libra.interq.or.jp