「セキュリティ」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(→‎ユーザー設定: ログイン失敗後の遅延時間の設定を翻訳して追加)
(→‎SSH: 二段階認証に用語を統一)
 
(5人の利用者による、間の33版が非表示)
16行目: 16行目:
 
==概念==
  
==概念==
 
*セキュリティを厳しくするあまりシステムが使い物にならなくなってしまう可能性があります。うまいやり方は度を越さない程度にセキュリティを強化します。
  
*セキュリティを厳しくするあまりシステムが使い物にならなくなってしまう可能性があります。うまいやり方は度を越さない程度にセキュリティを強化します。
−
*セキュリティを高めるために出来ることは数多く存在しますが、一番の脅威はいつだってユーザー自身です。セキュリティを考える時は、多層防御を考える必要があります。ある層が突破されたとしても、他の層が攻撃を防御しなくてはなりません。ただし全てのネットワークからマシンを切断して、金庫にしまって決して使わないかぎり、システムを100%セキュアにすることは不可能です。
 +
*セキュリティを高めるためにできることは数多く存在しますが、一番の脅威はいつだってユーザー自身です。セキュリティを考える時は、多層防御を考える必要があります。ある層が突破されたとしても、他の層が攻撃を防御しなくてはなりません。ただし全てのネットワークからマシンを切断して、金庫にしまって決して使わないかぎり、システムを100%セキュアにすることは不可能です。
 
*少しだけ病的なまでの心配性 (パラノイド) になりましょう。それは役に立ちます。そして疑り深くなってください。話がうますぎるように聞こえたら、おそらくその通りです。
  
*少しだけ病的なまでの心配性 (パラノイド) になりましょう。それは役に立ちます。そして疑り深くなってください。話がうますぎるように聞こえたら、おそらくその通りです。
 
*[[Wikipedia:ja:最小権限の原則|最小権限の原則]]: システムの各部位は使用に必要なことにだけしかアクセスできないようにするべきで、それ以上は必要ありません。
  
*[[Wikipedia:ja:最小権限の原則|最小権限の原則]]: システムの各部位は使用に必要なことにだけしかアクセスできないようにするべきで、それ以上は必要ありません。
25行目: 25行目:
 
===強力なパスワードの選び方===
  
===強力なパスワードの選び方===
   
−
パスワードは簡単に[[Wikipedia:ja:パスワードクラック|割り出されたり]]または個人情報から類推されないようにすることが重要です。そういうわけで、辞書に載っている単語やあなたの飼っている犬の名前などは使わないようにしましょう。パスワードは出来るだけ8文字以上で、小文字と大文字を混ぜてください。さらに数字や特殊文字も1文字以上含めると良いでしょう。当たり前ですが、長くて複雑なパスワードが基本的に良いパスワードとされます。
 +
パスワードは簡単に[[Wikipedia:ja:パスワードクラック|割り出されたり]]または個人情報から類推されないようにすることが重要です。そういうわけで、辞書に載っている単語やあなたの飼っている犬の名前などは使わないようにしましょう。パスワードはできるだけ8文字以上で、小文字と大文字を混ぜてください。さらに数字や特殊文字も1文字以上含めると良いでしょう。当たり前ですが、長くて複雑なパスワードが基本的に良いパスワードとされます。
   
 
{{Pkg|pwgen}} や {{AUR|apg}} などのツールは安全なパスワードを生成するのに役立ちます。
  
{{Pkg|pwgen}} や {{AUR|apg}} などのツールは安全なパスワードを生成するのに役立ちます。
41行目: 41行目:
   
 
デフォルトの Arch のハッシュ [[SHA パスワードハッシュ|sha512]] はとても強固で変更する必要はありません。デフォルトでは、{{ic|/etc/shadow}} にパスワードがハッシュ化されて保存され、root にだけ読み取り許可を与え、{{ic|/etc/passwd}} にはユーザー識別子だけが保存されます。従って、[[#root の制限|root ユーザーが安全]]である限り、ファイルが外部システムにコピーされたり解読されることはありえません。
  
デフォルトの Arch のハッシュ [[SHA パスワードハッシュ|sha512]] はとても強固で変更する必要はありません。デフォルトでは、{{ic|/etc/shadow}} にパスワードがハッシュ化されて保存され、root にだけ読み取り許可を与え、{{ic|/etc/passwd}} にはユーザー識別子だけが保存されます。従って、[[#root の制限|root ユーザーが安全]]である限り、ファイルが外部システムにコピーされたり解読されることはありえません。
  +
  +
パスワードは '''passwd''' コマンドで設定され、[[Wikipedia:Key stretching|キー ストレッチング]] と [[Wikipedia:Crypt (C)|crypt]] 関数を用いて、{{ic|/etc/shadow}} に保存されます。[[SHA パスワードハッシュ]]も参照してください。また、パスワードは [[Wikipedia:Salt (cryptography)|ソルティング]] されており、[[Wikipedia:Rainbow table|レインボー テーブル]] 攻撃から防御しています。
   
 
[http://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils How are passwords stored in Linux (Understanding hashing with shadow utils)] も参照してください。
  
[http://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils How are passwords stored in Linux (Understanding hashing with shadow utils)] も参照してください。
164行目: 166行目:
 
# chmod 700 /boot /etc/{iptables,arptables}
  
# chmod 700 /boot /etc/{iptables,arptables}
   
−
デフォルトの [[Umask]] を変更することで新しく作成したファイルのセキュリティを向上させることができます。[http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] はセキュリティを最大化させるために {{ic|077}} の umask を提案しています、これは新しいファイルの所有者以外のユーザーによる読み取りを出来なくします。umask を変更するには、[[Umask#マスクの値を設定]]を参照してください。
 +
デフォルトの [[Umask]] を変更することで新しく作成したファイルのセキュリティを向上させることができます。[http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] はセキュリティを最大化させるために {{ic|077}} の umask を提案しています、これは新しいファイルの所有者以外のユーザーによる読み取りをできなくします。umask を変更するには、[[Umask#マスクの値を設定]]を参照してください。
  +
  +
=== SUID ファイルと SGID ファイル ===
  +
  +
[[Wikipedia:ja:Setuid|Setuid]] ビットや Setgid ビットが設定されたファイルには注意しましょう。このようなファイルの例としては、以下があります。これらは {{ic|/usr/bin}} 内にあり、SUID ビットが設定されていて、root によって所有されています:
  +
  +
* gpasswd
  +
* pkexec
  +
* [[sudo]]
  +
* [[su]]
  +
* [[passwd]]
  +
* [[firejail]]
  +
  +
このような実行ファイルの主なリスクとして、特権昇格の脆弱性があります。例えば [[Wikipedia:Setuid#Security impact]] を参照してください。[https://www.cvedetails.com/vulnerability-list/vendor_id-16224/product_id-36412/Calibre-ebook-Calibre.html][https://www.cvedetails.com/product/32625/Sudo-Project-Sudo.html?vendor_id=15714][https://www.cvedetails.com/vulnerability-list/vendor_id-16191/Firejail-Project.html]
  +
  +
SUID ビットが設定されているが root によって所有されていないファイル、または SGID ビットが設定されているファイルは、''典型的には''潜在的なリスクがより小さいですが、理論上、そのようなファイルに脆弱性が存在している場合は、依然として損害を与える可能性があります。通常、代わりに[[ケイパビリティ]]を割り当てることによって、Setuid や Setgid の使用を回避することが可能です。
  +
  +
{{Tip|SUID/SGID 実行ファイルを含むパッケージを最新に保って、脆弱性からシステムを守ることが肝心です。}}
  +
  +
SUID ビットか SGID ビットを持つファイルを {{ic|/usr/bin}} から探すには:
  +
  +
$ find /usr/bin -perm "/u=s,g=s"
   
 
== ユーザー設定 ==
  
== ユーザー設定 ==
210行目: 233行目:
 
* soft nproc 100
  
* soft nproc 100
 
* hard nproc 200
  
* hard nproc 200
  +
  +
=== Wayland を使用する ===
  +
  +
[[Xorg]] よりも [[Wayland]] を使用することをお勧めします。Xorg の設計は現代のセキュリティ慣行より古く、多くの人が [https://security.stackexchange.com/questions/4641/why-are-people-saying-that-the-x-window-system-is-not-secure/4646#4646 は安全でないと考えています] 例えば、Xorg のアプリケーションは非アクティブな状態でもキーストロークを記録することがあります。
  +
  +
もし Xorg を実行しなければならないなら、[[Xorg#Rootless_Xorg|root での実行を避ける]]ことが推奨されます。Wayland 内では、XWayland 互換レイヤーは自動的に root レス Xorg を使用します。
   
 
== root の制限 ==
  
== root の制限 ==
 
root ユーザーは、定義上、システムで最も強力なユーザーです。このため、root ユーザーの権限を維持しながら害を及ぼす力を制限する、もしくは root ユーザーの行動をもっと追跡できるようにする方法が多数存在します。
  
root ユーザーは、定義上、システムで最も強力なユーザーです。このため、root ユーザーの権限を維持しながら害を及ぼす力を制限する、もしくは root ユーザーの行動をもっと追跡できるようにする方法が多数存在します。
   
−
===su の代わりに sudo を使う===
 +
=== su の代わりに sudo を使う ===
 
[[Su#セキュリティ|色々な理由]]から特権アクセスには [[su]] よりも [[sudo]] を使うほうが好ましいとされます。
  
[[Su#セキュリティ|色々な理由]]から特権アクセスには [[su]] よりも [[sudo]] を使うほうが好ましいとされます。
   
241行目: 270行目:
 
}}
  
}}
   
−
====sudo を使ってファイルを編集する====
 +
==== sudo を使ってファイルを編集する ====
 
root で {{ic|vim}} などのテキストエディタを使用するのはセキュリティ上の脆弱性になりえます。ユーザーは任意のシェルコマンドを実行でき、コマンドを実行したユーザーのログが残らないからです。これを解決するには、以下をシェルの設定ファイルに追加してください:
  
root で {{ic|vim}} などのテキストエディタを使用するのはセキュリティ上の脆弱性になりえます。ユーザーは任意のシェルコマンドを実行でき、コマンドを実行したユーザーのログが残らないからです。これを解決するには、以下をシェルの設定ファイルに追加してください:
   
248行目: 277行目:
 
ファイルの編集には {{ic|sudoedit filename}} または {{ic|sudo -e filename}} を使って下さい。自動的に {{ic|rvim}} によって {{ic|filename}} が編集されるようになり、テキストエディタからのシェルコマンドが無効になります。
  
ファイルの編集には {{ic|sudoedit filename}} または {{ic|sudo -e filename}} を使って下さい。自動的に {{ic|rvim}} によって {{ic|filename}} が編集されるようになり、テキストエディタからのシェルコマンドが無効になります。
   
−
===root ログインの制限===
 +
=== root ログインの制限 ===
 
[[sudo]] を適切に設定することで、ユーザビリティをあまり下げることなく完全な root アクセスを大分制限することが可能です。[[sudo]] を使える状態のまま root を無効化したい場合、{{ic|passwd -l root}} を使用します。
  
[[sudo]] を適切に設定することで、ユーザビリティをあまり下げることなく完全な root アクセスを大分制限することが可能です。[[sudo]] を使える状態のまま root を無効化したい場合、{{ic|passwd -l root}} を使用します。
   
−
====特定のユーザーだけに許可を与える====
 +
==== 特定のユーザーだけに許可を与える ====
 
[[Wikipedia:Pluggable authentication module|PAM]] の {{ic|pam_wheel.so}} は {{ic|wheel}} グループに入っているユーザーだけに {{ic|su}} を使用したログインを許可します。{{ic|/etc/pam.d/su}} と {{ic|/etc/pam.d/su-l}} の両方を編集して次の行をアンコメントしてください:
  
[[Wikipedia:Pluggable authentication module|PAM]] の {{ic|pam_wheel.so}} は {{ic|wheel}} グループに入っているユーザーだけに {{ic|su}} を使用したログインを許可します。{{ic|/etc/pam.d/su}} と {{ic|/etc/pam.d/su-l}} の両方を編集して次の行をアンコメントしてください:
 
{{bc|<nowiki>
  
{{bc|<nowiki>
259行目: 288行目:
 
特権コマンドを実行できる既存のユーザーだけが root でログインできるようになります。
  
特権コマンドを実行できる既存のユーザーだけが root でログインできるようになります。
   
−
====ssh ログインを拒否する====
 +
==== ssh ログインを拒否する ====
 
ローカルユーザーの root ログインを拒否したくない場合でも、[[SSH#root ログインを拒否する|SSH による root ログインを拒否]]するのがグッドプラクティスです。この目的は、ユーザーがリモートでシステムを完全に手にかける前にセキュリティ層を追加することにあります。
  
ローカルユーザーの root ログインを拒否したくない場合でも、[[SSH#root ログインを拒否する|SSH による root ログインを拒否]]するのがグッドプラクティスです。この目的は、ユーザーがリモートでシステムを完全に手にかける前にセキュリティ層を追加することにあります。
  +
  +
==== access.conf で許容されるログインの組み合わせを指定する ====
  +
  +
誰かが [[PAM]] でログインしようとすると、 {{ic|/etc/security/access.conf}} がそのログインプロパティに一致する最初の組み合わせをチェックします。そして、その組み合わせのルールに基づいて、試行が失敗するか成功するかが決まります。
  +
  +
+:root:LOCAL
  +
-:root:ALL
  +
  +
特定のグループやユーザーに対してルールを設定することができます。この例では、ユーザー archie は、wheel および adm グループに属するすべてのユーザーと同様に、ローカルでのログインを許可されています。それ以外のログインは拒否されます。
  +
  +
+:archie:LOCAL
  +
+:(wheel):LOCAL
  +
+:(adm):LOCAL
  +
-:ALL:ALL
  +
  +
詳しくは {{man|5|access.conf}} で確認してください。
   
 
==強制アクセス制御==
  
==強制アクセス制御==
280行目: 325行目:
 
[[アクセス制御リスト]] (Access Control List, ACL) は何らかの方法で直接ファイルシステムにルールを付加する代わりとなる手段です。ACL はプログラムの行動を許可された挙動のリストでチェックすることによりアクセス制御を実装しています。
  
[[アクセス制御リスト]] (Access Control List, ACL) は何らかの方法で直接ファイルシステムにルールを付加する代わりとなる手段です。ACL はプログラムの行動を許可された挙動のリストでチェックすることによりアクセス制御を実装しています。
   
−
==カーネルの防御==
 +
== カーネルの堅牢化 ==
   
 
=== カーネルの自己防衛機能/脆弱性攻撃対策 ===
  
=== カーネルの自己防衛機能/脆弱性攻撃対策 ===
   
−
{{pkg|linux-hardened}} パッケージは [https://github.com/thestinger/linux-hardened 基本的なカーネル堅牢化パッチセット] を使用しており {{pkg|linux}} パッケージよりもセキュリティを高めるコンパイルオプションを有効にしています。また、カスタムビルドすることでセキュリティ指向のデフォルト設定から、セキュリティとパフォーマンスを両立するように設定を変更することができます。詳しくは [https://wiki.gentoo.org/wiki/Hardened/Hardened_Kernel_Project Gentoo wiki の記事] を参照してください。現時点では前に存在した {{ic|linux-grsec}} パッケージ (grsecurity パッチは非公開となり有料になりました) と比較して強化ポイントが少なくなっていますが、上流の Kernel Self Protection Project と共同歩調をとって拡張が行われる予定です。出来る限り上流にマージしつつ、政治的な理由で変更が拒否されたり変更が来るのを待つことなくパッチを利用することができます。
 +
{{pkg|linux-hardened}} パッケージは、[https://github.com/anthraxx/linux-hardened 基本的なカーネル堅牢化パッチセット]と、{{pkg|linux}} パッケージよりもセキュリティに重点を置いたコンパイル時設定オプションを使用します。カスタムビルドでは、セキュリティ寄りのデフォルトとは異なる、セキュリティと性能の妥協点を選択することができます。
   
  +
しかし、このカーネルを使うといくつかのパッケージが動かなくなることに注意する必要があります。例えば
−
===カーネルログへのアクセスを制限する===
  
   
  +
* {{AUR|skypeforlinux-preview-bin}}
−
{{Note|{{pkg|linux-hardened}} ではデフォルトで有効になっています。}}
  
  +
* {{AUR|skypeforlinux-stable-bin}}
  +
* {{pkg|throttled}}
   
  +
[[NVIDIA]] などのアウトオブツリードライバを使用している場合、その [[DKMS]] パッケージに切り替える必要があるかもしれません。
−
カーネルログにはカーネルの脆弱性を突こうとしている攻撃者にとって有益な情報、保護が必要なメモリーアドレスなどが含まれています。{{ic|kernel.dmesg_restrict}} フラグは (デフォルトで root として実行しているプロセスしか持たない) {{ic|CAP_SYS_ADMIN}} ケイパビリティのないログへのアクセスを禁止します。
  
   
  +
==== ユーザー空間 ASLR の比較 ====
−
{{hc|/etc/sysctl.d/50-dmesg-restrict.conf|2=kernel.dmesg_restrict = 1}}
  
   
  +
{{pkg|linux-hardened}} パッケージは、アドレス空間配置ランダム化の改善された実装をユーザ空間のプロセスに対して提供します。{{pkg|paxtest}} コマンドを使うことで、提供されるエントロピーの推定値を得ることができます:
−
===proc ファイルシステムのカーネルポインタへのアクセスを制限する===
  
   
  +
===== 64 ビットプロセス =====
−
{{Note|{{pkg|linux-hardened}} ではデフォルトで {{ic|1=kptr_restrict=2}} と設定されています。}}
  
   
  +
{{hc|linux-hardened 5.4.21.a-1-hardened|
−
{{ic|kernel.kptr_restrict}} を有効にすると {{ic|CAP_SYSLOG}} のない通常ユーザーから {{ic|/proc/kallsyms}} のカーネルシンボルのアドレスが秘匿され、動的にアドレス・シンボルを解決するカーネル exploit が難しくなります。これは事前にコンパイルされた Arch Linux カーネルではあまり意味がありません、周到な攻撃者はカーネルパッケージをダウンロードしてそこから手動でシンボルを取得することができるからです。しかしながら自分でカーネルをコンパイルする場合は、ローカルの root 攻撃を減らす効果があります。ただし root 以外のユーザーで使用する場合いくつかの {{Pkg|perf}} コマンドが破壊されます (メインの {{Pkg|perf}} 機能には結局 root アクセスが必要になりますが)。詳しくは {{Bug|34323}} を見て下さい。
  
  +
Anonymous mapping randomization test : 32 quality bits (guessed)
  +
Heap randomization test (ET_EXEC) : 40 quality bits (guessed)
  +
Heap randomization test (PIE) : 40 quality bits (guessed)
  +
Main executable randomization (ET_EXEC) : 32 quality bits (guessed)
  +
Main executable randomization (PIE) : 32 quality bits (guessed)
  +
Shared library randomization test : 32 quality bits (guessed)
  +
VDSO randomization test : 32 quality bits (guessed)
  +
Stack randomization test (SEGMEXEC) : 40 quality bits (guessed)
  +
Stack randomization test (PAGEEXEC) : 40 quality bits (guessed)
  +
Arg/env randomization test (SEGMEXEC) : 44 quality bits (guessed)
  +
Arg/env randomization test (PAGEEXEC) : 44 quality bits (guessed)
  +
Offset to library randomisation (ET_EXEC): 34 quality bits (guessed)
  +
Offset to library randomisation (ET_DYN) : 34 quality bits (guessed)
  +
Randomization under memory exhaustion @~0: 32 bits (guessed)
  +
Randomization under memory exhaustion @0 : 32 bits (guessed)
  +
}}
   
  +
{{hc|linux 5.5.5-arch1-1|
−
{{hc|/etc/sysctl.d/50-kptr-restrict.conf|2=kernel.kptr_restrict = 1}}
  
  +
Anonymous mapping randomization test : 28 quality bits (guessed)
  +
Heap randomization test (ET_EXEC) : 28 quality bits (guessed)
  +
Heap randomization test (PIE) : 28 quality bits (guessed)
  +
Main executable randomization (ET_EXEC) : 28 quality bits (guessed)
  +
Main executable randomization (PIE) : 28 quality bits (guessed)
  +
Shared library randomization test : 28 quality bits (guessed)
  +
VDSO randomization test : 20 quality bits (guessed)
  +
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)
  +
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)
  +
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)
  +
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)
  +
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)
  +
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)
  +
Randomization under memory exhaustion @~0: 29 bits (guessed)
  +
Randomization under memory exhaustion @0 : 29 bits (guessed)
  +
}}
   
  +
{{hc|linux-lts 4.19.101-1-lts|
−
===BPF JIT コンパイラを無効にする===
  
  +
Anonymous mapping randomization test : 28 quality bits (guessed)
  +
Heap randomization test (ET_EXEC) : 28 quality bits (guessed)
  +
Heap randomization test (PIE) : 28 quality bits (guessed)
  +
Main executable randomization (ET_EXEC) : 28 quality bits (guessed)
  +
Main executable randomization (PIE) : 28 quality bits (guessed)
  +
Shared library randomization test : 28 quality bits (guessed)
  +
VDSO randomization test : 19 quality bits (guessed)
  +
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)
  +
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)
  +
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)
  +
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)
  +
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)
  +
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)
  +
Randomization under memory exhaustion @~0: 28 bits (guessed)
  +
Randomization under memory exhaustion @0 : 28 bits (guessed)
  +
}}
   
  +
===== 32 ビットプロセス (x86_64 カーネル上) =====
−
Linux カーネルにはパフォーマンス最適化のために BPF/Seccomp ルールセットをネイティブコードにコンパイルする機能が含まれています。最高レベルのセキュリティのために {{ic|net.core.bpf_jit_enable}} フラグは0にしておくべきです。
  
   
  +
{{hc|linux-hardened|
−
コンパイラは特定の領域では有用ですが、通常は役に立ちません。JIT コンパイラは攻撃者がヒープスプレー攻撃を行う機会を与え、カーネルのヒープが悪意のあるコードで満たされるかもしれません。このコードは不正な関数へのポインタの間接参照など、他の脆弱性攻撃によって実行される危険性があります。
  
  +
Anonymous mapping randomization test : 16 quality bits (guessed)
  +
Heap randomization test (ET_EXEC) : 22 quality bits (guessed)
  +
Heap randomization test (PIE) : 27 quality bits (guessed)
  +
Main executable randomization (ET_EXEC) : No randomization
  +
Main executable randomization (PIE) : 18 quality bits (guessed)
  +
Shared library randomization test : 16 quality bits (guessed)
  +
VDSO randomization test : 16 quality bits (guessed)
  +
Stack randomization test (SEGMEXEC) : 24 quality bits (guessed)
  +
Stack randomization test (PAGEEXEC) : 24 quality bits (guessed)
  +
Arg/env randomization test (SEGMEXEC) : 28 quality bits (guessed)
  +
Arg/env randomization test (PAGEEXEC) : 28 quality bits (guessed)
  +
Offset to library randomisation (ET_EXEC): 18 quality bits (guessed)
  +
Offset to library randomisation (ET_DYN) : 16 quality bits (guessed)
  +
Randomization under memory exhaustion @~0: 18 bits (guessed)
  +
Randomization under memory exhaustion @0 : 18 bits (guessed)
  +
}}
   
  +
{{hc|linux|
−
===ptrace スコープ===
  
  +
Anonymous mapping randomization test : 8 quality bits (guessed)
  +
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)
  +
Heap randomization test (PIE) : 13 quality bits (guessed)
  +
Main executable randomization (ET_EXEC) : No randomization
  +
Main executable randomization (PIE) : 8 quality bits (guessed)
  +
Shared library randomization test : 8 quality bits (guessed)
  +
VDSO randomization test : 8 quality bits (guessed)
  +
Stack randomization test (SEGMEXEC) : 19 quality bits (guessed)
  +
Stack randomization test (PAGEEXEC) : 19 quality bits (guessed)
  +
Arg/env randomization test (SEGMEXEC) : 11 quality bits (guessed)
  +
Arg/env randomization test (PAGEEXEC) : 11 quality bits (guessed)
  +
Offset to library randomisation (ET_EXEC): 8 quality bits (guessed)
  +
Offset to library randomisation (ET_DYN) : 13 quality bits (guessed)
  +
Randomization under memory exhaustion @~0: No randomization
  +
Randomization under memory exhaustion @0 : No randomization
  +
}}
   
  +
=== proc ファイルシステム内のカーネルポインタへのアクセスを制限する ===
−
{{ic|kernel.yama.ptrace_scope}} フラグによって、Arch は Yama LSM をデフォルトで有効にしています。このフラグはプロセスが {{ic|CAP_SYS_PTRACE}} のないスコープの外で他のプロセスに {{ic|ptrace}} コールを実行するのを止めます。多くのデバッグツールがいくつかの機能を使うためにこれを必要としますが、セキュリティの面では飛躍的な改善になります。この機能がないと、名前空間のような外部レイヤーを適用しないかぎり同一ユーザーで動作するプロセスの分割は基本的に行われません。デバッガを既存プロセスにアタッチできることはこの欠点のデモンストレーションです。
  
   
  +
{{ic|kernel.kptr_restrict}} を 1 に設定すると、{{ic|CAP_SYSLOG}} を持たない通常ユーザから {{ic|/proc/kallsyms}} 内のカーネルシンボルのアドレスが秘匿され、カーネルのエクスプロイトで動的にアドレス/シンボルを解決することが困難になります。これは、事前にコンパイルされた Arch Linux カーネルではあまり意味がありません。周到な攻撃者はカーネルパッケージをダウンロードして、そこから手動でシンボルを取得することができるからです。しかしながら、自分でカーネルをコンパイルする場合は、ローカルの root 攻撃を減らす効果があります。ただし、一部の {{Pkg|perf}} コマンドの機能が、root 以外のユーザによって使用されば場合に破壊されます (しかし、いずれにせよ多くの {{Pkg|perf}} コマンドは root アクセスを必要とします)。詳細は {{Bug|34323}} を参照してください。
−
====破壊される機能の例====
  
   
  +
{{ic|kernel.kptr_restrict}} を 2 に設定すると、{{ic|/proc/kallsyms}} 内のカーネルシンボルのアドレスが権限に依らず隠されます。
−
{{Note|{{ic|sudo}} を使って特定のユーザーに、パスワード有り無しで許可を与えたりすることで、root で以下のコマンドを実行することは可能です。}}
  
   
  +
{{hc|/etc/sysctl.d/51-kptr-restrict.conf|2=
−
* {{ic|gdb -p $PID}}
  
  +
kernel.kptr_restrict = 1
−
* {{ic|strace -p $PID}}
  
  +
}}
−
* {{ic|perf trace -p $PID}}
  
−
* {{ic|reptyr $PID}}
  
   
  +
{{Note|{{pkg|linux-hardened}} はデフォルトで {{ic|0}} ではなく {{ic|1=kptr_restrict=2}} を設定します。}}
−
=== リンクの [[Wikipedia:TOCTOU|TOCTOU]] 攻撃を防止する ===
  
   
  +
=== BPF の堅牢化 ===
−
この機能が追加された日時や根拠についてはこの [https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=800179c9b8a1e796e441674776d11cd4c05d61d7 commit メッセージ]を見て下さい。
  
   
  +
BPF は、実行時にカーネル内のバイトコードを動的にロードして実行するために使用されるシステムです。ネットワーク (XDP, tc など)、トレース (kprobes, uprobes, tracepoints など)、セキュリティ (seccomp など) など、多くの Linux カーネルサブシステムで使用されています。また、高度なネットワークセキュリティ、パフォーマンスプロファイリング、ダイナミックトレースにも有効です。
−
fs.protected_hardlinks = 1
  
−
fs.protected_symlinks = 1
  
   
  +
BPF はもともと [[Wikipedia:ja:Berkeley Packet Filter|Berkeley Packet Filter]] の頭文字をとったもので、オリジナルの古典的な BPF は BSD 用のパケットキャプチャツールに使われていたためです。これは最終的に拡張 BPF (eBPF) に発展し、その後まもなくただの BPF (頭字語ではありません) に改名されました。BPFはパケットフィルタリングツールの実装に使われることがありますが、 iptables や netfilter のようなパケットフィルタリングツールと混同しないでください。
−
{{Note|現在は {{ic|/usr/lib/sysctl.d/50-default.conf}} によってデフォルトで有効にされています。}}
  
   
  +
BPF のコードは解釈されるか、[[Wikipedia:ja:実行時コンパイラ|Just-In-Time (JIT) コンパイラ]]を使ってコンパイルされるかのどちらかです。Arch のカーネルは {{ic|CONFIG_BPF_JIT_ALWAYS_ON}} でビルドされており、BPF インタープリタを無効にして全ての BPF を JIT コンパイラでコンパイルするよう強制しています。これにより、攻撃者が BPF を使って SPECTRE 型の脆弱性を悪用した特権昇格攻撃をすることが難しくなります。詳しくは、[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=290af86629b25ffd1ed6232c4e9107da031705cb CONFIG_BPF_JIT_ALWAYS_ON を導入したカーネルパッチ]を参照してください。
−
===hidepid===
  
   
  +
カーネルは JIT コンパイルされた BPF に対して、パフォーマンスと多くの BPF プログラムをトレース・デバッグする能力を犠牲にして、ある種の JIT スプレー攻撃を軽減するための堅牢化機能を備えています。この機能は、{{ic|net.core.bpf_jit_harden}} を {{ic|1}} (非特権コードの堅牢化を有効化する) か {{ic|2}} (全てのコードの堅牢化を有効化する) に設定することで有効化できます。
−
通常は {{ic|/proc}} から他のユーザーのプロセスを確認することができますが、カーネルにはプロセスを秘匿する機能が存在し {{ic|proc}} ファイルシステムを {{ic|1=hidepid=}} と {{ic|1=gid=}} オプションを使ってマウントすることで有効になります。詳しいドキュメントは [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/proc.txt#n1919 こちら] に存在します。
  
   
  +
詳しくは、[https://docs.kernel.org/admin-guide/sysctl/net.html カーネルドキュメント] の {{ic|net.core.bpf_*}} 設定を参照してください。
−
プロセスを隠すことで侵入者は動作中のプロセスに関する情報を得るのが難しくなります (どのデーモンが特権権限で動作しているか、プログラムの実行に使われているユーザーはどれか、など)。さらに、引数で機密情報を渡すような問題のあるプログラムから情報が漏れてしまうことを防ぎます。
  
   
  +
{{Tip|
−
{{Pkg|filesystem}} パッケージに含まれている {{ic|proc}} [[ユーザーとグループ#システムグループ|グループ]]はホワイトリストとして機能し、グループに含まれているユーザーは他のユーザーのプロセス情報を閲覧することが可能です。{{ic|/proc/<pid>}} ディレクトリから他のユーザーの情報を得る必要があるユーザーやサービスがある場合、[[ユーザーとグループ#グループ管理|グループにユーザーを追加]]してください。
  
  +
* {{Pkg|linux-hardened}} では、デフォルトで {{ic|1=net.core.bpf_jit_harden=2}} が設定されており、{{ic|0}} ではありません。
  +
* デフォルトでは、BPF プログラムは非特権ユーザでも実行可能です。この挙動を変更するには {{ic|1=kernel.unprivileged_bpf_disabled=1}} を設定してください [https://access.redhat.com/security/cve/cve-2021-33624]。
  +
}}
  +
  +
=== ptrace スコープ ===
  +
  +
{{man|2|ptrace}} システムコールは、あるプロセス ("tracer") が他のプロセス ("tracee") の実行を監視、制御し、tracee のメモリとレジスタを検査、変更するための手段を提供します。通常、{{ic|ptrace}} は ''gdb'' や ''strace''、''perf''、''reptyr'' などのデバッグツールによって使用されます。しかし、他のプロセスからデータを読んだり、他のプロセスの制御を奪ったりする手段を悪意のあるプロセスにも提供してしまいます。
  +
  +
Arch では、{{ic|kernel.yama.ptrace_scope}} [[カーネルパラメータ]]を提供する [https://docs.kernel.org/admin-guide/LSM/Yama.html Yama LSM] がデフォルトで有効化されています。このパラメータはデフォルトで {{ic|1}} (制限) に設定されており、{{ic|CAP_SYS_PTRACE}} [[ケイパビリティ]]も特権も持たない tracer が制限されたスコープ外で {{ic|ptrace}} コールを実行できないようにしています。これは、古典的なパーミッションと比べてセキュリティ上大きな改善です。このモジュールが無いと、同じユーザとして実行されているプロセスを隔てるものがなくなってしまいます ({{man|7|pid_namespaces}} などの他のセキュリティレイヤーがない場合)。
  +
  +
{{Note|デフォルトでは、[[sudo]] を使うなどして、{{ic|ptrace}} を必要とするツールを特権プロセスとして実行することができます。}}
  +
  +
デバッグツールを使う必要がない場合は、システムを堅牢化するために {{ic|kernel.yama.ptrace_scope}} を {{ic|2}} (管理者限定) や {{ic|3}} ({{ic|ptrace}} を禁止) に設定することを検討してください。
  +
  +
=== hidepid ===
  +
  +
{{Warning|
  +
* これは、サンドボックスと [[Xorg]] 内で実行するアプリケーションなど、特定のアプリケーションで問題を発生させる場合があります (回避策を見てください)。
  +
* {{Pkg|systemd}} > 237.64-1 を使用している場合、これは [[D-Bus]]、[[Polkit]]、[[PulseAudio]]、そして [[bluetooth]] で問題を発生させます。
  +
}}
  +
  +
カーネルには、{{ic|proc}} ファイルシステムを {{ic|1=hidepid=}} オプションと {{ic|1=gid=}} オプションを使ってマウントすることで、他のユーザのプロセス (通常、{{ic|/proc}} でアクセス可能) を非特権ユーザから秘匿する機能があります。これらのマウントオプションは https://docs.kernel.org/filesystems/proc.html でドキュメント化されています。
  +
  +
これにより、侵入者が動作中のプロセスの情報 (特権で動作しているデーモンがあるか、他のユーザが機密情報を扱うプログラムを実行しているか、他のユーザがプログラムを実行しているか) を得る作業を複雑化し、ユーザが特定のプログラムを実行しているかどうかを知るのを不可能にし (ただし、そのプログラムがそれ自体の挙動で存在を他者に知られることがないとする)、さらに、貧弱に書かれたプログラムが機密情報をプログラム引数を介して渡したとしてもローカルの盗聴者から守られます。
  +
  +
{{ic|proc}} [[ユーザーとグループ#システムグループ#グループ]] ({{Pkg|filesystem}} パッケージによって提供されています) は、他のユーザのプロセス情報を得ることのできるユーザのホワイトリストとして機能します。ユーザやサービスが自身以外の {{ic|/proc/<pid>}} ディレクトリにアクセスする必要がある場合、そのユーザまたはサービスを[[ユーザーとグループ#グループ管理|proc グループに追加してください]]。
  +
  +
例えば、プロセスの情報を {{ic|proc}} グループに属さない他のユーザから隠すには:
   
−
{{ic|proc}} グループに含まれていないユーザーに他のユーザーのプロセス情報を表示しない設定は以下の通りです:
  
 
{{hc|/etc/fstab|2=
  
{{hc|/etc/fstab|2=
 
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0
  
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0
 
}}
  
}}
   
−
[[Xorg]] を動作させるために systemd-logind の例外を追加する必要があります:
 +
ユーザのセッションを正しく動作させるために、''systemd-logind'' を例外として追加する必要があります:
  +
 
{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=
  
{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=
 
[Service]
  
[Service]
 
SupplementaryGroups=proc
  
SupplementaryGroups=proc
 
}}
  
}}
  +
  +
=== モジュールのロードを制限する ===
  +
  +
デフォルトの Arch カーネルは {{ic|CONFIG_MODULE_SIG_ALL}} が有効で、{{Pkg|linux}} パッケージの一部としてビルドされた全てのカーネルモジュールに署名します。これにより、カーネルは有効なキーで署名されたモジュールだけをロードするように制限できます。実際、これはローカルでコンパイルされた、もしくは {{Pkg|virtualbox-host-modules-arch}} などのパッケージによって提供された、ツリー外のモジュールは全てロードできないことを意味します。
  +
  +
カーネルモジュールの読み込みは {{ic|1=module.sig_enforce=1}} [[カーネルパラメータ]]を設定することで制限することができます。詳細は[https://docs.kernel.org/admin-guide/module-signing.html カーネルドキュメント]で見られます。
  +
  +
=== kexec を無効にする ===
  +
  +
Kexec は、現在実行中のカーネルを置き換えることを可能にします。
  +
  +
{{hc|/etc/sysctl.d/51-kexec-restrict.conf|2=
  +
kernel.kexec_load_disabled = 1
  +
}}
  +
  +
{{Tip|kexec は {{pkg|linux-hardened}} でデフォルトで無効になっています。}}
  +
  +
=== カーネルロックダウンモード ===
  +
  +
Linux 5.4 から、オプションの[https://mjg59.dreamwidth.org/55105.html ロックダウン機能]がカーネルに[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aefcf2f4b58155d27340ba5f9ddbe9513da8286d 追加されました]。これは、UID 0 (root) とカーネルの間の境界を強化することを目的としています。この機能を有効にすると、ハードウェアやカーネルへの低レベルなアクセスに依存している一部のアプリケーションは動作しなくなる可能性があります。
  +
  +
ロックダウンを使用するには、LSM が初期化され、ロックダウンモードが設定されている必要があります。
  +
  +
[[カーネル#公式サポートカーネル|公式にサポートされているカーネル]]は全て LSM を初期化しますが、ロックダウンモードを強制しません。
  +
  +
{{Tip|有効化されている LSM は {{ic|cat /sys/kernel/security/lsm}} を実行することで確認することができます。}}
  +
  +
ロックダウンには2つの動作モードがあります:
  +
  +
* {{ic|integrity}}: ユーザーランドが実行中のカーネルを変更できるカーネル機能 (kexec、bpf) は無効化されます。
  +
* {{ic|confidentiality}}: ユーザーランドがカーネルから機密情報を抽出するためのカーネルの機能も無効化されます。
  +
  +
特定の脅威モデルで指示がない限り、{{ic|integrity}} を使用することが推奨されます。
  +
  +
実行時にカーネルのロックダウンを有効にするには、以下を実行してください:
  +
  +
# echo ''mode'' > /sys/kernel/security/lockdown
  +
  +
起動時にカーネルのロックダウンを有効にするには、{{ic|1=lockdown=''mode''}} [[カーネルパラメータ]]を使用してください:
  +
  +
{{Note|
  +
* カーネルロックダウンを実行時に無効化することはできません。
  +
* カーネルロックダウンは、[[ハイバネート]]を無効化します。
  +
}}
  +
  +
{{man|7|kernel_lockdown}} も参照してください。
  +
  +
=== Linux Kernel Runtime Guard (LKRG) ===
  +
  +
[https://www.openwall.com/lkrg/ LKRG] ({{AUR|lkrg-dkms}}) は、カーネルの整合性チェックとエクスプロイト行為の検出を行うカーネルモジュールです。
   
 
== アプリケーションのサンドボックス化 ==
  
== アプリケーションのサンドボックス化 ==
   
 
{{Note|標準の Arch カーネルではユーザー名前空間の {{ic|CONFIG_USER_NS}} が設定されていないため、特定のサンドボックス機能がアプリケーションから使えない場合があります。{{pkg|linux-hardened}} パッケージでは有効になっていますが、非特権での使用はデフォルトで無効になっています。{{ic|kernel.unprivileged_userns_clone}} の [[sysctl]] を {{ic|1}} に設定することで使用できるようになりますが、ローカルの権限昇格を引き起こす可能性が高くなるので注意してください。}}
  
{{Note|標準の Arch カーネルではユーザー名前空間の {{ic|CONFIG_USER_NS}} が設定されていないため、特定のサンドボックス機能がアプリケーションから使えない場合があります。{{pkg|linux-hardened}} パッケージでは有効になっていますが、非特権での使用はデフォルトで無効になっています。{{ic|kernel.unprivileged_userns_clone}} の [[sysctl]] を {{ic|1}} に設定することで使用できるようになりますが、ローカルの権限昇格を引き起こす可能性が高くなるので注意してください。}}
  +
  +
{{Warning|{{Pkg|linux}} (5.1.8 およびそれ以降)、{{Pkg|linux-lts}} (4.19.55-2 およびそれ以降)、{{Pkg|linux-zen}} (5.1.14.zen1-2 およびそれ以降) においては、{{ic|kernel.unprivileged_userns_clone}} [[sysctl]] が {{ic|0}} に設定されていない限り、非特権ユーザの名前空間の利用 ({{ic|CONFIG_USER_NS_UNPRIVILEGED}}) がデフォルトで有効化されています。これはローカルの特権昇格の攻撃対象領域を大幅に増加させるので、これを手動で無効化するか {{Pkg|linux-hardened}} カーネルを使用することが推奨されます。詳細は {{Bug|36969}} を見てください。}}
   
 
=== Firejail ===
  
=== Firejail ===
367行目: 572行目:
 
=== Linux Containers ===
  
=== Linux Containers ===
   
−
他の手段 (KVM や Virtualbox) よりも強力な分離が必要なときは [[Linux Containers]] を選択するのもよいでしょう。LXC は仮想ハードウェアを使って擬似的な chroot で既存のカーネル上で動作します。
 +
他の手段 (KVM や Virtualboxのような完全仮想化を除く) よりも強力な分離が必要なときは [[Linux Containers]] を選択するのもよいでしょう。LXC は仮想ハードウェアを使って擬似的な chroot で既存のカーネル上で動作します。
   
 
=== 他の仮想化手段 ===
  
=== 他の仮想化手段 ===
389行目: 594行目:
 
[[SSH 鍵#パスワードログインの無効化|SSH 鍵を必要]]としない [[Secure Shell]] を使うのは避けましょう。これは[[Wikipedia:ja:総当たり攻撃|総当たり攻撃]]を防ぎます。また、[[Fail2ban]] や [[Sshguard]] はログを監視して [[iptables|iptables ルール]]を書き込む方式の保護を提供しますが、攻撃者がアドレスを識別して管理者からのパケットのように偽装することができるため、サービスの妨害が行われる危険性があります。
  
[[SSH 鍵#パスワードログインの無効化|SSH 鍵を必要]]としない [[Secure Shell]] を使うのは避けましょう。これは[[Wikipedia:ja:総当たり攻撃|総当たり攻撃]]を防ぎます。また、[[Fail2ban]] や [[Sshguard]] はログを監視して [[iptables|iptables ルール]]を書き込む方式の保護を提供しますが、攻撃者がアドレスを識別して管理者からのパケットのように偽装することができるため、サービスの妨害が行われる危険性があります。
   
−
2段階認証によって認証を強化することができます。[[Google Authenticator]] はワンタイムパスコード (OTP) を使用する2段階認証方式を提供します。
 +
二段階認証によって認証を強化することができます。[[Google Authenticator]] はワンタイムパスコード (OTP) を使用する二段階認証方式を提供します。
   
 
[[Secure Shell#root ログインを拒否する|root ログインを拒否する]]のは、侵入追跡と root アクセス前のセキュリティレイヤを追加するという両方の面でグッドプラクティスです。
  
[[Secure Shell#root ログインを拒否する|root ログインを拒否する]]のは、侵入追跡と root アクセス前のセキュリティレイヤを追加するという両方の面でグッドプラクティスです。
416行目: 621行目:
 
お好きなブラウザを開いて'''信頼できない'''サイトとして表示されれば、ブラックリストが上手く機能しています。
  
お好きなブラウザを開いて'''信頼できない'''サイトとして表示されれば、ブラックリストが上手く機能しています。
   
  +
== 物理セキュリティ ==
−
==パッケージの認証==
  
−
パッケージの署名が適正に使われていないと [http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview パッケージマネージャへの攻撃] が考えられ、さらに [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html 適切な署名システム] を使っているパッケージマネージャにも影響を与える可能性があります。Arch はデフォルトでパッケージの署名を使用しており5つの信頼されたマスターキーによる web of trust を使っています。詳しくは [[Pacman-key]] を見て下さい。
  
−  
−
== NVD/CVE アラートを購読する ==
  
−  
−
National Vulnerability Database による Common Vulnerabilities and Exposure (CVE) を講読する ([http://nvd.nist.gov/download.cfm NVD のダウンロードページ])。また、[https://security.archlinux.org/ Arch Linux セキュリティトラッカー] は Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG), CVE データセットをまとめた情報を提供しています。[[en2:Arch CVE Monitoring Team|Arch CVE モニタリングチーム]]も見てください。
  
−  
−
{{Warning|無理に部分アップデートをしないでください。Arch Linux によってサポートされている手段ではなく、問題が発生する可能性があります。ひとつのコンポーネントをアップグレードする時はシステム全体をアップグレードしてください。システムアップデートをほとんどやらないとアップデートプロセスが複雑になる可能性があります。}}
  
   
−
==物理セキュリティ==
  
 
{{Note|リモート攻撃からコンピュータを守りたいだけの場合はこのセクションは無視してかまいません。}}
  
{{Note|リモート攻撃からコンピュータを守りたいだけの場合はこのセクションは無視してかまいません。}}
   
 
十分な時間とリソースさえあればコンピュータへの物理的なアクセスは root アクセスになります。しかしながら、十分な防御策を張ることで''実用的で''高いレベルのセキュリティを得ることができます。
  
十分な時間とリソースさえあればコンピュータへの物理的なアクセスは root アクセスになります。しかしながら、十分な防御策を張ることで''実用的で''高いレベルのセキュリティを得ることができます。
   
−
攻撃者は悪意のある IEEE 1394 (FireWire), Thunderbolt, PCI Express デバイスを取り付けることでメモリーへの完全なアクセスを手に入れることができ、次に起動した時には簡単にコンピュータの完全なコントロールを手中に収めることができます [http://www.breaknenter.org/projects/inception/]。これを防ぐために出来ることは限られており、悪意のあるファームウェアをドライブに書き込むなどハードウェア自体の改変に対処することは不可能です。ただし、攻撃者の大部分にはこうした知識がなく実行されることはほとんどありません。
 +
攻撃者は悪意のある IEEE 1394 (FireWire), Thunderbolt, PCI Express デバイスを取り付けることでメモリーへの完全なアクセスを手に入れることができ、次に起動した時には簡単にコンピュータの完全なコントロールを手中に収めることができます [http://www.breaknenter.org/projects/inception/]。これを防ぐためにできることは限られており、悪意のあるファームウェアをドライブに書き込むなどハードウェア自体の改変に対処することは不可能です。ただし、攻撃者の大部分にはこうした知識がなく実行されることはほとんどありません。
   
 
[[#ディスク暗号化|ディスク暗号化]]はコンピュータが盗まれた場合にデータへのアクセスを防止しますが、あなたが次にログインしたときにデータを取得するために悪意のあるファームウェアが能力のある攻撃者によってインストールされる可能性があります。
  
[[#ディスク暗号化|ディスク暗号化]]はコンピュータが盗まれた場合にデータへのアクセスを防止しますが、あなたが次にログインしたときにデータを取得するために悪意のあるファームウェアが能力のある攻撃者によってインストールされる可能性があります。
438行目: 635行目:
 
BIOS にパスワードを追加することによってリムーバブルメディアから誰かが起動する (これはコンピュータへの root アクセスと基本的に同義です) のを予防します。使用しているドライブがブートの順番で一番最初に来ることを確認して、可能であれば他のドライブのブートを無効にしてください。
  
BIOS にパスワードを追加することによってリムーバブルメディアから誰かが起動する (これはコンピュータへの root アクセスと基本的に同義です) のを予防します。使用しているドライブがブートの順番で一番最初に来ることを確認して、可能であれば他のドライブのブートを無効にしてください。
   
−
===ブートローダー===
 +
=== ブートローダー ===
   
−
ブートローダーの保護はとても重要です。{{ic|1=init=/bin/sh}} というたった一つのカーネルパラメータで、全てのユーザー・ログイン制限が全くの無に帰します。
 +
[[Arch ブートプロセス#ブートローダー|ブートローダー]] を保護することは非常に重要です。保護されていないブートローダは、例えば {{ic|1=init=/bin/sh}} を設定することでログインの制限を回避することができます。[[カーネルパラメータ]] でシェルに直接ブートするようにします。
   
−
====Syslinux====
 +
==== Syslinux ====
   
 
Syslinux は[[Syslinux#セキュリティ|ブートローダーのパスワード保護]]をサポートしています。メニューのアイテムごとにパスワードを設定したり、ブートローダー全体にパスワードの保護を設定することが可能です。
  
Syslinux は[[Syslinux#セキュリティ|ブートローダーのパスワード保護]]をサポートしています。メニューのアイテムごとにパスワードを設定したり、ブートローダー全体にパスワードの保護を設定することが可能です。
   
−
====GRUB====
 +
==== GRUB ====
   
−
[[GRUB]] も同じくブートローダーのパスワードをサポートしています。詳しくは [[GRUB/ヒントとテクニック#GRUB メニューのパスワード保護]] を見て下さい。
 +
[[GRUB]] はブートローダのパスワードもサポートしています。詳しくは [[GRUB/ヒントとテクニック#GRUB メニューのパスワード保護|GRUB メニューのパスワード保護]] を参照してください。[[GRUB/ヒントとテクニック# GRUB メニューのパスワード保護|暗号化 /boot]] もサポートしていますが、これはブートローダコードの一部だけを暗号化しないままにしています。GRUB の設定、[[カーネル]]、[[initramfs]] は暗号化されています。
   
  +
=== セキュアブート ===
−
===root でのコンソールログインを拒む===
  
  +
−
コンソールからの root ログインを拒否するよう設定を変更すれば侵入者がシステムへのアクセスを取得するのを難しくすることができます。侵入者はシステムに存在するユーザーの名前とそのユーザーのパスワードを考えなくてはならなくなります。コンソールによって root がログインできるようになっている場合、侵入者が解き当てるのはパスワードだけで十分になります。
  
  +
[[セキュアブート]] は [[UEFI]] の機能で、コンピュータが起動するファイルの認証を可能にするものです。これは、起動パーティション内のファイルを置き換えるような、いくつかの [https://ja.wikipedia.org/wiki/%E6%82%AA%E6%84%8F%E3%81%82%E3%82%8B%E3%83%A1%E3%82%A4%E3%83%89%E6%94%BB%E6%92%83 悪意あるメイド攻撃] を防止するのに役立つ。通常、コンピュータにはベンダー (OEM) によって登録されたキーが付属しています。しかし、これを取り外して、コンピュータを「セットアップモード」にし、ユーザーが自分のキーを登録・管理できるようにすることができます。
−
コンソールの root ログインのブロックは {{ic|/etc/securetty}} の tty 行をコメントアウトすることで行います。
  
  +
−
{{hc|/etc/securetty|
  
  +
セキュアブートのページでは、[https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Implementing_Secure_Boot using your own keys] によってセキュアブートを設定する方法を案内しています。
−
#tty1
  
  +
−
}}
  
  +
=== トラステッドプラットフォームモジュール（TPM） ===
  +
  +
[[Trusted Platform Module|TPM]] は、暗号鍵が埋め込まれたハードウェア・マイクロプロセッサです。これは、最近のほとんどのコンピュータの基本的な信頼性の根源を形成し、ブートチェーンのエンドツーエンドの検証を可能にします。内部スマートカードとして使用したり、コンピュータ上で動作するファームウェアを証明したり、改ざん防止とブルートフォース耐性のあるストアにユーザーがシークレットに挿入することができます。
  +
  +
=== リムーバブル フラッシュ ドライブ上のブートパーティション ===
  +
  +
ブートパーティションをフラッシュドライブに置き、それがないとシステムが起動しないようにする、というのはよくあるアイデアです。このアイデアの支持者はしばしば [[セキュリティ#ディスク暗号化|ディスク暗号化]] を併用し、ブートパーティションに置かれた [https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_/boot_and_a_detached_LUKS_header_on_USBdetached encryption headers] を使っている人もいます。
   
  +
この方法は [https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_/boot_and_a_detached_LUKS_header_on_USB encrypting /boot] と統合することも可能です。
−
ブロックしたい tty 全てで同じようにコメントアウトしてください。
  
−
変更の効果を確認するには、一つの行だけをコメントアウトしてから特定のコンソールに移って root でのログインを試行してみてください。{{ic|Login incorrect}} というメッセージが表示されるはずです。ブロックされたことを確認したら、戻ってから残りの tty 行をコメントアウトしてください。
  
−
{{Note|{{ic|ttyS0}} が表示された場合は、シリアルコンソール用です。同様に Xen 仮想化システムでは {{ic|hvc0}} は管理者用です。}}
  
   
 
=== 自動ログアウト ===
  
=== 自動ログアウト ===
480行目: 682行目:
 
シェルで何かコマンドが動作している間はこのタイムアウトは動作しないので注意してください (例: SSH セッションや {{ic|TMOUT}} をサポートしていない他のシェル)。しかしながら固まった GDM/Xorg を root で再起動するのに VC を使っているような場合は、とても有用です。
  
シェルで何かコマンドが動作している間はこのタイムアウトは動作しないので注意してください (例: SSH セッションや {{ic|TMOUT}} をサポートしていない他のシェル)。しかしながら固まった GDM/Xorg を root で再起動するのに VC を使っているような場合は、とても有用です。
   
  +
=== 不正なUSBデバイスから保護する ===
−
=== X からの TTY アクセスをブロック ===
  
   
  +
[[Usbguard]] は、デバイスの属性に基づく基本的なホワイトリストおよびブラックリスト機能を実装することで、不正な USB デバイス (別名 [https://ja.wikipedia.org/wiki/BadUSB BadUSB], [https://github.com/samyk/poisontap PoisonTap] または [https://lanturtle.com/ LanTurtle]) からコンピューターを保護できるソフトウェアフレームワークです。
−
[[Xorg#TTY のアクセスをブロック]]を見てください。
  
   
−
== パッケージの再ビルド ==
 +
=== 揮発性データの収集 ===
   
  +
電源が入っているコンピュータは、[https://fedvte.usalearning.gov/courses/CSI/course/videos/pdf/CSI_D01_S05_T01_STEP.pdf volatile data collection] に対して脆弱である可能性があります。コンピュータの電源を入れる必要がない時や、コンピュータの物理的な安全性が一時的に損なわれる場合（例:セキュリティチェックポイントを通過する時）には、コンピュータの電源を完全に切ることがベストプラクティスです。
−
パッケージを再ビルドして無駄な機能を省くことで攻撃対象を減らすことができます。例えば {{Pkg|bzip2}} から {{ic|bzip2recover}} を外してビルドすることで [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189] に対処できます。ハードニングフラグは手動で設定したり {{Pkg|hardening-wrapper}}{{Broken package link|パッケージが存在しません}} で適用できます。
  
   
  +
== パッケージ ==
−
=== カスタムハードニングフラグ ===
  
   
  +
=== パッケージの認証 ===
−
以下のビルドフラグを {{Ic|/etc/makepkg.conf}} で有効にできます。将来的に [https://lists.archlinux.org/pipermail/arch-dev-public/2016-October/028405.html Arch のデフォルトフラグ] となることが予定されています:
  
  +
パッケージの署名が適正に使われていないと [http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview パッケージマネージャへの攻撃] が考えられ、さらに [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html 適切な署名システム] を使っているパッケージマネージャにも影響を与える可能性があります。Arch はデフォルトでパッケージの署名を使用しており5つの信頼されたマスターキーによる web of trust を使っています。詳しくは [[Pacman-key]] を見て下さい。
   
  +
=== アップグレード ===
−
* LDFLAGS: {{Ic|z,now}}
  
−
* [[Wikipedia:CFLAGS|CFLAGS]]: {{Ic|-fno-plt -fstack-check}}
  
   
  +
定期的に [[システムメンテナンス#システムのアップグレード|システムのアップグレード]] を行うことが重要です。
−
{{AUR|hardening-check}} を使って標準の {{Ic|bzip2}} バイナリの状態を確認:
  
   
  +
=== 脆弱性アラートの確認 ===
−
$ hardening check -v /usr/bin/bzip2
  
−
/usr/bin/bzip2:
  
−
Position Independent Executable: no, normal executable!
  
−
Stack protected: yes
  
−
Fortify Source functions: no, only unprotected functions found!
  
−
unprotected: fread
  
−
unprotected: fprintf
  
−
unprotected: strcat
  
−
unprotected: strncpy
  
−
unprotected: strcpy
  
−
Read-only relocations: no, not found!
  
−
Immediate binding: no, not found!
  
   
  +
National Vulnerability Database が提供する Common Vulnerabilities and Exposure (CVE) Security Alert の更新を購読し、[https://nvd.nist.gov/download.cfm NVD Download webpage] で見つけてください。[https://security.archlinux.org/ Arch Linux Security Tracker] は Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG), CVE データセットを表形式でまとめた、特に有用なリソースです。ツール {{Pkg|arch-audit}} は実行中のシステムに影響を与える脆弱性をチェックするために使われます。グラフィカルなシステムトレイである {{Pkg|arch-audit-gtk}} も使うことができます。[https://wiki.archlinux.org/title/Arch_Security_Team Arch Security Team]も参照してください。
−
{{AUR|hardening-check}} を使って堅牢化した {{Ic|bzip2}} バイナリの状態を確認:
 
   
  +
特にメインレポジトリや AUR 以外の手段でソフトウェアをインストールしている場合は、あなたが使っているソフトウェアのリリース通知を購読することも検討すべきです。いくつかのソフトウェアには、セキュリティに関する通知を受け取るために購読できるメーリングリストがあります。ソースコードホスティングサイトはしばしば新しいリリースの RSS フィードを提供しています。
−
$ hardening check -v /usr/bin/bzip2
  
−
/usr/bin/bzip2:
  
−
Position Independent Executable: yes
  
−
Stack protected: yes
  
−
Fortify Source functions: yes (some protected functions found)
  
−
unprotected: memcpy
  
−
unprotected: fread
  
−
unprotected: strncpy
  
−
protected: fprintf
  
−
protected: strcat
  
−
Read-only relocations: yes
  
−
Immediate binding: yes
  
   
  +
=== パッケージの再ビルド ===
−
{{Pkg|checksec}} を使って標準の {{Ic|bzip2}} バイナリの状態を確認:
  
   
  +
攻撃対象領域を減らす手段として、パッケージをリビルドし、不要な関数や機能を削除することができます。例えば、{{Pkg|bzip2}} は [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189] を回避するために {{ic|bzip2recover}} を使わずにリビルドすることが可能です。カスタムハードニングフラグは、手動またはラッパーを介して適用することもできます。
−
$ checksec -f /usr/bin/bzip2
  
−
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE
  
−
No RELRO Canary found NX enabled No PIE No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2
  
   
  +
{| class="wikitable"
−
{{Pkg|checksec}} を使って堅牢化した {{Ic|bzip2}} バイナリの状態を確認:
 
  +
! フラグ !! 目的
−  
  +
|-
−
$ checksec -f /usr/bin/bzip2
  
  +
| -D_FORTIFY_SOURCE=2 || ランタイムバッファオーバーフローの検出
−
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE
  
  +
|-
−
Full RELRO Canary found NX enabled PIE enabled No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2
  
  +
| -D_GLIBCXX_ASSERTIONS || C++ の文字列とコンテナのランタイム境界チェック
  +
|-
  +
| -fasynchronous-unwind-tables || バックトレースの信頼性向上
  +
|-
  +
| -fexceptions || テーブルベースのスレッドキャンセルを有効にする
  +
|-
  +
| -fpie -Wl,-pie || 実行可能ファイルに対する完全な ASLR
  +
|-
  +
| -fpic -shared || 共有ライブラリのテキスト再配置を行わない
  +
|-
  +
| -fplugin=annobin || ハードニング品質管理用データの作成
  +
|-
  +
| -fstack-clash-protection || スタックオーバーフロー検出の信頼性向上
  +
|-
  +
| -fstack-protector or -fstack-protector-all || スタックスマッシュプロテクター
  +
|-
  +
| -fstack-protector-strong || 同様に
  +
|-
  +
| -g || デバッグ情報を生成する
  +
|-
  +
| -grecord-gcc-switches || デバッグ情報にコンパイラのフラグを格納する
  +
|-
  +
| -mcet -fcf-protection || 制御フローの完全性保護
  +
|-
  +
| -O2 || 推奨される最適化
  +
|-
  +
| -pipe || 一時ファイルを回避し、ビルドを高速化します。
  +
|-
  +
| -Wall || 推奨されるコンパイラの警告
  +
|-
  +
| -Werror=format-security || 安全でない可能性のあるフォーマット文字列の引数を拒否する
  +
|-
  +
| -Werror=implicit-function-declaration || 関数プロトタイプの欠落を却下する
  +
|-
  +
| -Wl,-z,defs || アンダーリンクの検出と拒否
  +
|-
  +
| -Wl,-z,now || 遅延バインディングを無効にする
  +
|-
  +
| -Wl,-z,relro || 移設後の読み出し専用セグメント
  +
|}
   
  +
* [https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc/ Flags and info ソース]
−
{{Note|PIE を有効にするとパッケージによっては問題が発生します。その場合は {{Ic|1=export HARDENING_PIE=0}} で無効にできます。}}
  
   
 
== 参照 ==
  
== 参照 ==

2024年9月5日 (木) 20:51時点における最新版

関連記事

この記事では Arch Linux システムを防御するための推奨事項とベストプラクティスを並べています。

目次

概念

  • セキュリティを厳しくするあまりシステムが使い物にならなくなってしまう可能性があります。うまいやり方は度を越さない程度にセキュリティを強化します。
  • セキュリティを高めるためにできることは数多く存在しますが、一番の脅威はいつだってユーザー自身です。セキュリティを考える時は、多層防御を考える必要があります。ある層が突破されたとしても、他の層が攻撃を防御しなくてはなりません。ただし全てのネットワークからマシンを切断して、金庫にしまって決して使わないかぎり、システムを100%セキュアにすることは不可能です。
  • 少しだけ病的なまでの心配性 (パラノイド) になりましょう。それは役に立ちます。そして疑り深くなってください。話がうますぎるように聞こえたら、おそらくその通りです。
  • 最小権限の原則: システムの各部位は使用に必要なことにだけしかアクセスできないようにするべきで、それ以上は必要ありません。

パスワード

パスワードは安全な linux システムのかぎです。パスワードはユーザーアカウント, 暗号化されたファイルシステム, SSH/GPG 鍵などを守ります。コンピュータを使用する人を信頼するのに使う主要な手段なので、安全なパスワードを選んでそれを保護するというのがセキュリティの大部分と言っても過言ではありません。

強力なパスワードの選び方

パスワードは簡単に割り出されたりまたは個人情報から類推されないようにすることが重要です。そういうわけで、辞書に載っている単語やあなたの飼っている犬の名前などは使わないようにしましょう。パスワードはできるだけ8文字以上で、小文字と大文字を混ぜてください。さらに数字や特殊文字も1文字以上含めると良いでしょう。当たり前ですが、長くて複雑なパスワードが基本的に良いパスワードとされます。

pwgen や apgAUR などのツールは安全なパスワードを生成するのに役立ちます。

また、ある文章の各単語の一番最初を取ってパスワードを作ることもできます。 例えば “the girl is walking down the rainy street” なら “t6!WdtR5” とパスワードにすることができます。この方法はパスワードを覚えるのをずっと簡単にしてくれます。さらに、入力するのが面倒くさくなりますがパスワードを “The girl is walking down the rainy street" にすることも可能です。

パスワードの管理

強固なパスワードを選び出したら、それを安全に保管してください。心理操作やショルダーサーフィンに注意したり、セキュアでないサーバーから必要以上に情報が流出するのをふせぐためにパスワードを再利用しないようにしてください。pass, keepassxAUR, gnome-keyring などのツールは大量の複雑なパスワードを管理するのに役立ちます。Lastpass はデバイス間で同期するためにオンラインで暗号化されたパスワードを保存するサービスですが、クローズドソースのコードと外部の企業の両方を信頼する必要があります。

概して、安全なパスワードは覚えにくいからといって安全でないパスワードを使ってはいけません。パスワードはバランスを取る必要があります。弱いパスワードをたくさん作るよりは、安全なパスワードの暗号化されたデータベースを作り、一つの強いマスターパスワードで守るほうが良いでしょう。パスワードを紙に書くのも、物理的なセキュリティを必要としますがソフトウェアの脆弱性を防ぐ点では同じくらい有効です [1]。

パスワードのハッシュ

警告: SHA512 は高速なハッシュ関数として設計されており、パスワードのハッシュ用には作られていません。bcrypt や scrypt などに比べて SHA512 によってハッシュ化されたパスワードには攻撃者ははるかに高速にブルートフォース攻撃をすることができます。

デフォルトの Arch のハッシュ sha512 はとても強固で変更する必要はありません。デフォルトでは、/etc/shadow にパスワードがハッシュ化されて保存され、root にだけ読み取り許可を与え、/etc/passwd にはユーザー識別子だけが保存されます。従って、root ユーザーが安全である限り、ファイルが外部システムにコピーされたり解読されることはありえません。

パスワードは passwd コマンドで設定され、キー ストレッチング と crypt 関数を用いて、/etc/shadow に保存されます。SHA パスワードハッシュも参照してください。また、パスワードは ソルティング されており、レインボー テーブル 攻撃から防御しています。

How are passwords stored in Linux (Understanding hashing with shadow utils) も参照してください。

pam_cracklib を用いた強力なパスワードの強制

pam_cracklib は辞書攻撃からの防御を提供し、システム全体で強制するパスワードポリシーの設定を補助します。

警告: root アカウントはこのポリシーの影響を受けません。
ノート: root アカウントを利用することで望ましい/設定されたポリシーを迂回したユーザーのパスワードを設定することができます。これは一時的なパスワードを設定するときに便利です。

例えば以下のようなポリシーを強制させたい場合:

  • エラー時に2回パスワードプロンプト
  • 最小で10文字の長さ (minlen オプション)
  • 新しくパスワードを設定する場合、少なくとも6文字は古いパスワードと異なる (difok オプション)
  • 少なくとも1文字数字を含む (dcredit オプション)
  • 少なくとも1文字は大文字を含む (ucredit オプション)
  • 少なくとも1文字は異なる文字を含む (ocredit オプション)
  • 少なくとも1文字は小文字を含む (lcredit オプション)

/etc/pam.d/passwd ファイルを以下のように書き換えます: 

#%PAM-1.0
password required pam_cracklib.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1
password required pam_unix.so use_authtok sha512 shadow

password required pam_unix.so use_authtok でパスワードのプロンプトを表示するときに pam_unix モジュールではなく pam_cracklib によるプロンプトを使うようになります。

詳細な情報については pam_cracklib(8) と pam_unix(8) の man ページを参照してください。

CPU

マイクロコード

CPU のマイクロコードに対する重要なセキュリティ更新プログラムをインストールする方法については、マイクロコード を参照してください。

ハードウェアの脆弱性

CPU の中には、ハードウェアの脆弱性を含んでいるものがあります。これらの脆弱性の一覧と、特定の使用シナリオに合わせてこれらの脆弱性を緩和するためにカーネルをカスタマイズするのに役立つ緩和策の選択ガイドについては、kernel documentation on hardware vulnerabilities を参照してください。

既知の脆弱性の影響を受けているかどうかを確認するには、以下を実行してください。 

$ grep -r . /sys/devices/system/cpu/vulnerabilities/

ほとんどの場合、カーネルとマイクロコードを更新することで、脆弱性を軽減することができます。

同時マルチスレッディング (ハイパースレッディング)

同時マルチスレッディング] (SMT) は、インテル CPU のハイパースレッディングとも呼ばれ、L1 Terminal Fault および Microarchitectural Data Sampling 脆弱性の原因となる可能性のあるハードウェア機能です。Linux カーネルとマイクロコードのアップデートには、既知の脆弱性に対する緩和策が含まれていますが、信頼できない仮想化ゲストが存在する場合、特定の CPU で SMT を無効にしたほうが良い場合があります。

SMT は、システムのファームウェアで無効にできることがよくあります。詳細については、マザーボードまたはシステムのドキュメントを参照してください。また、以下の カーネルパラメータ を追加することで、カーネルで SMT を無効にすることができます。 

l1tf=full,force mds=full,nosmt mitigations=auto,nosmt nosmt=force

メモリ

ハード化された malloc

hardened_malloc (hardened_mallocAUR, hardened-malloc-gitAUR) は glibc の malloc() をハード化した代替品です。元々は Android の Bionic と musl に組み込むために開発されましたが、 x86_64 アーキテクチャの標準 Linux ディストリビューションのサポートにも組み込みました。

hardened_malloc はまだ glibc に統合されていませんが（支援とプルリクエストは歓迎します）、LD_PRELOAD と一緒に簡単に使用することができます。これまでのテストでは、 /etc/ld.so.preload でグローバルに有効にすると、 一握りのアプリケーションにしか問題を起こしません。例えば、getrandom が標準のホワイトリストにないため、seccomp 環境フラグが無効でないと man は正常に動作しませんが、これはシステムコールを追加して再構築すれば簡単に修正可能です。hardened_malloc は性能上のコストがあるので、どの実装を使うかは攻撃対象領域と性能上の必要性に基づいてケースバイケースで決めるとよいでしょう。

スタンドアロンで試すには、hardened-malloc-preload ラッパー スクリプトを使用するか、適切なプリロード値でアプリケーションを手動で開始します。 

LD_PRELOAD="/usr/lib/libhardened_malloc.so" /usr/bin/firefox

Firejail の正しい使い方は、その wiki ページにあります。また、hardened_malloc の設定可能なビルドオプションは、githubレポで見つけることができます。

ストレージ

ディスク暗号化

ディスク暗号化、特に強固なパスフレーズによる完全ディスク暗号化は、物理的なリカバリからデータを守る唯一の方法です。コンピュータの電源がオフになっていて問題のディスクがアンマウントされている時は完璧なセキュリティを提供します。

しかしながら、コンピュータの電源が入れられてドライブがマウントされると、そのデータは暗号化されていないドライブと同じように無防備になります。そのためデータが必要なくなったときはすぐにデータのパーティションをアンマウントするのが最善です。

Dm-crypt など特定のプログラムでは、ループファイルを物理ボリュームとして暗号化することができます。これはシステムの特定部分だけを守りたいときに完全なディスク暗号化の代わりの選択肢となりえます。

ファイルシステム

現在カーネルは fs.protected_hardlinks や fs.protected_symlinks sysctl スイッチが有効になっていればハードリンクやシンボリックリンクに関するセキュリティの問題を解決するので、world-writable なディレクトリを分離させるセキュリティ的な利点はもはや存在しません。

それでもディスク容量が消耗したときのダメージを低減させる荒っぽい方法として world-writable なディレクトリを含むパーティションが分割されることがあります。しかしながら、サービスを落とすには /var や /tmp などのパーティションを一杯にするだけで十分です。この問題の対処についてはもっと柔軟性のある方法が存在します (クォータなど)、またファイルシステムによっては関連する機能を持っていることがあります (btrfs はサブボリュームにクォータを設定できます)。

マウントオプション

最小権限の原則に従って、パーティションは (機能性を失わない限りで) 最も制限的なマウントオプションを使ってマウントすると良いでしょう。

  • nodev: ファイルシステム上のキャラクタ・ブロック特殊デバイスを解釈しない。
  • nosuid: set-user-identifier や set-group-identifier ビットの効果を許可しない。
  • noexec: マウントされたファイルシステム上の全てのバイナリの直接実行を許可しない。
ノート: データパーティションはいつでも nodev, nosuid, noexec でマウントするべきです。
パーティション nodev nosuid noexec
/var yes yes yes [1] [2]
/home yes yes yes (wine や steam を使用しない場合 [2])
/dev/shm yes yes yes
/tmp yes yes no (パッケージをコンパイルできなくなる可能性があります)
/boot yes yes yes

[1] パッケージによっては (例えば nvidia-dkms) /var で exec を必要とすることがあるので注意してください。

[2] noexec がパーティションに設定されている場合、Qt 5.8 以上では QML を使用するアプリケーションがクラッシュしたり機能しなくなることがあります。解決方法は Qt#Qt 5.8 で QML を使用するアプリケーションがクラッシュあるいは動作しないを参照。

ファイルシステムのパーミッション

デフォルトのファイルシステムのパーミッションはほぼ全ての読み取りアクセスが許可されているため、パーミッションを変更することで http や nobody ユーザーなど root 以外のアカウントへのアクセスを手に入れた攻撃者から重要な情報を隠すことができます。

例えば: 

# chmod 700 /boot /etc/{iptables,arptables}

デフォルトの Umask を変更することで新しく作成したファイルのセキュリティを向上させることができます。NSA RHEL5 Security Guide はセキュリティを最大化させるために 077 の umask を提案しています、これは新しいファイルの所有者以外のユーザーによる読み取りをできなくします。umask を変更するには、Umask#マスクの値を設定を参照してください。

SUID ファイルと SGID ファイル

Setuid ビットや Setgid ビットが設定されたファイルには注意しましょう。このようなファイルの例としては、以下があります。これらは /usr/bin 内にあり、SUID ビットが設定されていて、root によって所有されています:

このような実行ファイルの主なリスクとして、特権昇格の脆弱性があります。例えば Wikipedia:Setuid#Security impact を参照してください。[2][3][4]

SUID ビットが設定されているが root によって所有されていないファイル、または SGID ビットが設定されているファイルは、典型的には潜在的なリスクがより小さいですが、理論上、そのようなファイルに脆弱性が存在している場合は、依然として損害を与える可能性があります。通常、代わりにケイパビリティを割り当てることによって、Setuid や Setgid の使用を回避することが可能です。

ヒント: SUID/SGID 実行ファイルを含むパッケージを最新に保って、脆弱性からシステムを守ることが肝心です。

SUID ビットか SGID ビットを持つファイルを /usr/bin から探すには: 

$ find /usr/bin -perm "/u=s,g=s"

ユーザー設定

root アカウントを日常的に使用しない

最小特権の原則に従い、root ユーザーを日常的に使用しないようにしてください。システムを使用する各人に非特権ユーザーアカウントを作成するか。一時的な特権アクセスには、必要に応じて sudo を使用する。

ログイン失敗後の遅延時間の設定

以下の行を /etc/pam.d/system-login に追加し、ログインに失敗した際に最低4秒の遅延を追加します。 

/etc/pam.d/system-login
auth optional pam_faildelay.so delay=4000000

4000000 は遅延させる時間をマイクロ秒単位で指定します。

3回ログインを失敗したユーザーをロックアウトする

pambase 20200721.1-2 の時点では 、デフォルトで pam_faillock.so が有効になっており、15分間に3回ログインに失敗すると10分間ユーザをロックアウトします (FS#67644 を参照してください) このロックアウトはパスワード認証 (例:ログインと sudo) にのみ適用され、SSH 経由の公開鍵認証はそのまま利用可能です。 完全なサービス拒否を防ぐために、このロックアウトは root では無効になっています。

ユーザーをロック解除するには、次のようにします。 

$ faillock --reset --user username

デフォルトでは、ロック機構は /run/faillock/ にあるユーザーごとのファイルです。ディレクトリの所有者は root ですが、ファイルの所有者はユーザーなので、 faillock コマンドはファイルを空にするだけで、root は必要ありません。

モジュール pam_faillock.so は、ファイル /etc/security/faillock.conf で設定することが可能です。ロックアウトのパラメータです。

  • unlock_time - ロックアウト時間 (秒単位、デフォルトは10分)
  • fail_interval - ロックアウトに失敗するとロックアウトされる時間 (秒単位、デフォルトは15分)
  • deny - ロックアウトするまでに何回ログインに失敗するか (デフォルトは 3)
ノート: deny = 0 はロックアウトを無効化します

デフォルトでは、すべてのユーザーロックは再起動後に失われます。攻撃者がマシンをリブートできるのであれば、ロックは持続させた方が安全です。ロックを持続させるには、/etc/security/faillock.conf の dir パラメータを /var/lib/faillock に変更する必要があります。

変更を反映させるために再起動する必要はありません。root アカウントのロックアウトを有効にする、集中ログイン (LDAP など) を無効にするなど、さらなる設定オプションについては faillock.conf(5) を参照してください。

プロセスの数を制限する

信頼できないユーザーが大量に存在するシステムでは、一度に実行できるプロセスの数を制限して、フォーク爆弾などのサービス拒否攻撃を予防することが重要です。ユーザーやグループごとに実行できるプロセスの数は /etc/security/limits.conf で定義することができ、デフォルトでは空になっています。以下の値をファイルに追加すると、実行できるプロセスが100個までに制限されます。prlimit コマンドを使って一時的に上げられる最大数も200個までに制限します。ユーザーが普段実行するプロセスの数や、管理するハードウェアにあわせて適切な値に変更してください。 

* soft nproc 100
* hard nproc 200

Wayland を使用する

Xorg よりも Wayland を使用することをお勧めします。Xorg の設計は現代のセキュリティ慣行より古く、多くの人が は安全でないと考えています 例えば、Xorg のアプリケーションは非アクティブな状態でもキーストロークを記録することがあります。

もし Xorg を実行しなければならないなら、root での実行を避けることが推奨されます。Wayland 内では、XWayland 互換レイヤーは自動的に root レス Xorg を使用します。

root の制限

root ユーザーは、定義上、システムで最も強力なユーザーです。このため、root ユーザーの権限を維持しながら害を及ぼす力を制限する、もしくは root ユーザーの行動をもっと追跡できるようにする方法が多数存在します。

su の代わりに sudo を使う

色々な理由から特権アクセスには su よりも sudo を使うほうが好ましいとされます。

  • 通常の権限しか持たないユーザーが実行した特権コマンドのログを保持します。
  • root アクセスを必要とする各ユーザーに root ユーザーのパスワードを与える必要がありません。
  • 完全な root ターミナルは作成されないため、sudo は root アクセスが必要ないコマンドを偶発的に root で実行してしまうことを防止します。これは最小権限の原則と合っています。
  • 一つのコマンドを実行するためだけに完全な root アクセスを与える代わりに、ユーザーごとに個々のプログラムを有効にすることができます。例えば、ユーザー alice に特定のプログラムへのアクセス権限を与えるには:
# visudo

/etc/sudoers
alice ALL = NOPASSWD: /path/to/program

また、全てのユーザーに個別のコマンドを許可することも可能です。通常ユーザーでサーバーから Samba 共有をマウントするには: 

%users ALL=/sbin/mount.cifs,/sbin/umount.cifs

これによって users グループのメンバーである全てのユーザーが全てのマシン (ALL) から /sbin/mount.cifs や /sbin/umount.cifs コマンドを実行できるようになります。

ヒント: visudo で vi の代わりに nano を使うには: 
/etc/sudoers
Defaults editor=/usr/bin/rnano

# EDITOR=nano visudo のエクスポートは何にでも EDITOR として使うことができるためにセキュリティリスクとされています。

sudo を使ってファイルを編集する

root で vim などのテキストエディタを使用するのはセキュリティ上の脆弱性になりえます。ユーザーは任意のシェルコマンドを実行でき、コマンドを実行したユーザーのログが残らないからです。これを解決するには、以下をシェルの設定ファイルに追加してください: 

export SUDO_EDITOR=rvim

ファイルの編集には sudoedit filename または sudo -e filename を使って下さい。自動的に rvim によって filename が編集されるようになり、テキストエディタからのシェルコマンドが無効になります。

root ログインの制限

sudo を適切に設定することで、ユーザビリティをあまり下げることなく完全な root アクセスを大分制限することが可能です。sudo を使える状態のまま root を無効化したい場合、passwd -l root を使用します。

特定のユーザーだけに許可を与える

PAM の pam_wheel.so は wheel グループに入っているユーザーだけに su を使用したログインを許可します。/etc/pam.d/su と /etc/pam.d/su-l の両方を編集して次の行をアンコメントしてください: 

# Uncomment the following line to require a user to be in the "wheel" group.
auth		required	pam_wheel.so use_uid

特権コマンドを実行できる既存のユーザーだけが root でログインできるようになります。

ssh ログインを拒否する

ローカルユーザーの root ログインを拒否したくない場合でも、SSH による root ログインを拒否するのがグッドプラクティスです。この目的は、ユーザーがリモートでシステムを完全に手にかける前にセキュリティ層を追加することにあります。

access.conf で許容されるログインの組み合わせを指定する

誰かが PAM でログインしようとすると、 /etc/security/access.conf がそのログインプロパティに一致する最初の組み合わせをチェックします。そして、その組み合わせのルールに基づいて、試行が失敗するか成功するかが決まります。 

+:root:LOCAL
-:root:ALL

特定のグループやユーザーに対してルールを設定することができます。この例では、ユーザー archie は、wheel および adm グループに属するすべてのユーザーと同様に、ローカルでのログインを許可されています。それ以外のログインは拒否されます。 

+:archie:LOCAL
+:(wheel):LOCAL
+:(adm):LOCAL
-:ALL:ALL

詳しくは access.conf(5) で確認してください。

強制アクセス制御

強制アクセス制御 (Mandatory Access Control, MAC) は Arch やほとんどの Linux ディストリビューションで使われている任意アクセス制御 (Discretionary Access Control, DAC) とは大きく異なるタイプのセキュリティポリシーです。原則的に MAC ではシステムに影響を与えるプログラムの行動は全てセキュリティルールセットによってチェックを受けます。このルールセットは、DAC とは対照的に、ユーザーが変更することは不可能です。実装方法は色々と異なるタイプが存在しますが、強制アクセス制御を使うことで実質的にコンピュータのセキュリティを著しく向上させることになります。

パス名 MAC

パス名ベースのアクセス制御は指定されたファイルのパスに基づいてパーミッションを与えるというシンプルな形式のアクセス制御です。この形式のアクセス制御の欠点としてはファイルが移動されてもパーミッションはファイルと一緒に付いていかないということが挙げられます。プラス面となるのは、パス名ベースの MAC はラベルベースの MAC と異なり、幅広いファイルシステムに実装できることです。

  • AppArmor は Canonical によって開発されている MAC 実装で SELinux に比べて"簡単"になっています。
  • Tomoyo はもうひとつのシンプルで、使いやすい強制アクセス制御を提供するシステムです。利用と実装の両面でシンプルになるように設計されており、依存するライブラリがとても少なくなっています。

ラベル MAC

ラベルベースのアクセス制御ではファイルの拡張属性を使ってセキュリティパーミッションを管理します。このシステムはセキュリティの機能においてパス名ベースの MAC よりも間違いなく柔軟性が高い一方、拡張属性をサポートしているファイルシステムでしか動作しません。

  • SELinux は、Linux セキュリティを向上させる NSA プロジェクトに基づいており、システムユーザーやロールとは完全に独立して MAC を実装しています。成長してオリジナルの設定が変わっていくシステムのコントロールを簡単に維持できる、極めて強固なマルチレベル MAC ポリシー実装を提供します。

アクセス制御リスト

アクセス制御リスト (Access Control List, ACL) は何らかの方法で直接ファイルシステムにルールを付加する代わりとなる手段です。ACL はプログラムの行動を許可された挙動のリストでチェックすることによりアクセス制御を実装しています。

カーネルの堅牢化

カーネルの自己防衛機能/脆弱性攻撃対策

linux-hardened パッケージは、基本的なカーネル堅牢化パッチセットと、linux パッケージよりもセキュリティに重点を置いたコンパイル時設定オプションを使用します。カスタムビルドでは、セキュリティ寄りのデフォルトとは異なる、セキュリティと性能の妥協点を選択することができます。

しかし、このカーネルを使うといくつかのパッケージが動かなくなることに注意する必要があります。例えば

NVIDIA などのアウトオブツリードライバを使用している場合、その DKMS パッケージに切り替える必要があるかもしれません。

ユーザー空間 ASLR の比較

linux-hardened パッケージは、アドレス空間配置ランダム化の改善された実装をユーザ空間のプロセスに対して提供します。paxtest コマンドを使うことで、提供されるエントロピーの推定値を得ることができます:

64 ビットプロセス
linux-hardened 5.4.21.a-1-hardened
Anonymous mapping randomization test     : 32 quality bits (guessed)
Heap randomization test (ET_EXEC)        : 40 quality bits (guessed)
Heap randomization test (PIE)            : 40 quality bits (guessed)
Main executable randomization (ET_EXEC)  : 32 quality bits (guessed)
Main executable randomization (PIE)      : 32 quality bits (guessed)
Shared library randomization test        : 32 quality bits (guessed)
VDSO randomization test                  : 32 quality bits (guessed)
Stack randomization test (SEGMEXEC)      : 40 quality bits (guessed)
Stack randomization test (PAGEEXEC)      : 40 quality bits (guessed)
Arg/env randomization test (SEGMEXEC)    : 44 quality bits (guessed)
Arg/env randomization test (PAGEEXEC)    : 44 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 34 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 34 quality bits (guessed)
Randomization under memory exhaustion @~0: 32 bits (guessed)
Randomization under memory exhaustion @0 : 32 bits (guessed)

linux 5.5.5-arch1-1
Anonymous mapping randomization test     : 28 quality bits (guessed)
Heap randomization test (ET_EXEC)        : 28 quality bits (guessed)
Heap randomization test (PIE)            : 28 quality bits (guessed)
Main executable randomization (ET_EXEC)  : 28 quality bits (guessed)
Main executable randomization (PIE)      : 28 quality bits (guessed)
Shared library randomization test        : 28 quality bits (guessed)
VDSO randomization test                  : 20 quality bits (guessed)
Stack randomization test (SEGMEXEC)      : 30 quality bits (guessed)
Stack randomization test (PAGEEXEC)      : 30 quality bits (guessed)
Arg/env randomization test (SEGMEXEC)    : 22 quality bits (guessed)
Arg/env randomization test (PAGEEXEC)    : 22 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)
Randomization under memory exhaustion @~0: 29 bits (guessed)
Randomization under memory exhaustion @0 : 29 bits (guessed)

linux-lts 4.19.101-1-lts
Anonymous mapping randomization test     : 28 quality bits (guessed)
Heap randomization test (ET_EXEC)        : 28 quality bits (guessed)
Heap randomization test (PIE)            : 28 quality bits (guessed)
Main executable randomization (ET_EXEC)  : 28 quality bits (guessed)
Main executable randomization (PIE)      : 28 quality bits (guessed)
Shared library randomization test        : 28 quality bits (guessed)
VDSO randomization test                  : 19 quality bits (guessed)
Stack randomization test (SEGMEXEC)      : 30 quality bits (guessed)
Stack randomization test (PAGEEXEC)      : 30 quality bits (guessed)
Arg/env randomization test (SEGMEXEC)    : 22 quality bits (guessed)
Arg/env randomization test (PAGEEXEC)    : 22 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)
Randomization under memory exhaustion @~0: 28 bits (guessed)
Randomization under memory exhaustion @0 : 28 bits (guessed)
32 ビットプロセス (x86_64 カーネル上)
linux-hardened
Anonymous mapping randomization test     : 16 quality bits (guessed)
Heap randomization test (ET_EXEC)        : 22 quality bits (guessed)
Heap randomization test (PIE)            : 27 quality bits (guessed)
Main executable randomization (ET_EXEC)  : No randomization
Main executable randomization (PIE)      : 18 quality bits (guessed)
Shared library randomization test        : 16 quality bits (guessed)
VDSO randomization test                  : 16 quality bits (guessed)
Stack randomization test (SEGMEXEC)      : 24 quality bits (guessed)
Stack randomization test (PAGEEXEC)      : 24 quality bits (guessed)
Arg/env randomization test (SEGMEXEC)    : 28 quality bits (guessed)
Arg/env randomization test (PAGEEXEC)    : 28 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 18 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 16 quality bits (guessed)
Randomization under memory exhaustion @~0: 18 bits (guessed)
Randomization under memory exhaustion @0 : 18 bits (guessed)

linux
Anonymous mapping randomization test     : 8 quality bits (guessed)
Heap randomization test (ET_EXEC)        : 13 quality bits (guessed)
Heap randomization test (PIE)            : 13 quality bits (guessed)
Main executable randomization (ET_EXEC)  : No randomization
Main executable randomization (PIE)      : 8 quality bits (guessed)
Shared library randomization test        : 8 quality bits (guessed)
VDSO randomization test                  : 8 quality bits (guessed)
Stack randomization test (SEGMEXEC)      : 19 quality bits (guessed)
Stack randomization test (PAGEEXEC)      : 19 quality bits (guessed)
Arg/env randomization test (SEGMEXEC)    : 11 quality bits (guessed)
Arg/env randomization test (PAGEEXEC)    : 11 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 8 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 13 quality bits (guessed)
Randomization under memory exhaustion @~0: No randomization
Randomization under memory exhaustion @0 : No randomization

proc ファイルシステム内のカーネルポインタへのアクセスを制限する

kernel.kptr_restrict を 1 に設定すると、CAP_SYSLOG を持たない通常ユーザから /proc/kallsyms 内のカーネルシンボルのアドレスが秘匿され、カーネルのエクスプロイトで動的にアドレス/シンボルを解決することが困難になります。これは、事前にコンパイルされた Arch Linux カーネルではあまり意味がありません。周到な攻撃者はカーネルパッケージをダウンロードして、そこから手動でシンボルを取得することができるからです。しかしながら、自分でカーネルをコンパイルする場合は、ローカルの root 攻撃を減らす効果があります。ただし、一部の perf コマンドの機能が、root 以外のユーザによって使用されば場合に破壊されます (しかし、いずれにせよ多くの perf コマンドは root アクセスを必要とします)。詳細は FS#34323 を参照してください。

kernel.kptr_restrict を 2 に設定すると、/proc/kallsyms 内のカーネルシンボルのアドレスが権限に依らず隠されます。 

/etc/sysctl.d/51-kptr-restrict.conf
kernel.kptr_restrict = 1
ノート: linux-hardened はデフォルトで 0 ではなく kptr_restrict=2 を設定します。

BPF の堅牢化

BPF は、実行時にカーネル内のバイトコードを動的にロードして実行するために使用されるシステムです。ネットワーク (XDP, tc など)、トレース (kprobes, uprobes, tracepoints など)、セキュリティ (seccomp など) など、多くの Linux カーネルサブシステムで使用されています。また、高度なネットワークセキュリティ、パフォーマンスプロファイリング、ダイナミックトレースにも有効です。

BPF はもともと Berkeley Packet Filter の頭文字をとったもので、オリジナルの古典的な BPF は BSD 用のパケットキャプチャツールに使われていたためです。これは最終的に拡張 BPF (eBPF) に発展し、その後まもなくただの BPF (頭字語ではありません) に改名されました。BPFはパケットフィルタリングツールの実装に使われることがありますが、 iptables や netfilter のようなパケットフィルタリングツールと混同しないでください。

BPF のコードは解釈されるか、Just-In-Time (JIT) コンパイラを使ってコンパイルされるかのどちらかです。Arch のカーネルは CONFIG_BPF_JIT_ALWAYS_ON でビルドされており、BPF インタープリタを無効にして全ての BPF を JIT コンパイラでコンパイルするよう強制しています。これにより、攻撃者が BPF を使って SPECTRE 型の脆弱性を悪用した特権昇格攻撃をすることが難しくなります。詳しくは、CONFIG_BPF_JIT_ALWAYS_ON を導入したカーネルパッチを参照してください。

カーネルは JIT コンパイルされた BPF に対して、パフォーマンスと多くの BPF プログラムをトレース・デバッグする能力を犠牲にして、ある種の JIT スプレー攻撃を軽減するための堅牢化機能を備えています。この機能は、net.core.bpf_jit_harden を 1 (非特権コードの堅牢化を有効化する) か 2 (全てのコードの堅牢化を有効化する) に設定することで有効化できます。

詳しくは、カーネルドキュメント の net.core.bpf_* 設定を参照してください。

ヒント:
  • linux-hardened では、デフォルトで net.core.bpf_jit_harden=2 が設定されており、0 ではありません。
  • デフォルトでは、BPF プログラムは非特権ユーザでも実行可能です。この挙動を変更するには kernel.unprivileged_bpf_disabled=1 を設定してください [5]。

ptrace スコープ

ptrace(2) システムコールは、あるプロセス ("tracer") が他のプロセス ("tracee") の実行を監視、制御し、tracee のメモリとレジスタを検査、変更するための手段を提供します。通常、ptrace は gdb や strace、perf、reptyr などのデバッグツールによって使用されます。しかし、他のプロセスからデータを読んだり、他のプロセスの制御を奪ったりする手段を悪意のあるプロセスにも提供してしまいます。

Arch では、kernel.yama.ptrace_scope カーネルパラメータを提供する Yama LSM がデフォルトで有効化されています。このパラメータはデフォルトで 1 (制限) に設定されており、CAP_SYS_PTRACE ケイパビリティも特権も持たない tracer が制限されたスコープ外で ptrace コールを実行できないようにしています。これは、古典的なパーミッションと比べてセキュリティ上大きな改善です。このモジュールが無いと、同じユーザとして実行されているプロセスを隔てるものがなくなってしまいます (pid_namespaces(7) などの他のセキュリティレイヤーがない場合)。

ノート: デフォルトでは、sudo を使うなどして、ptrace を必要とするツールを特権プロセスとして実行することができます。

デバッグツールを使う必要がない場合は、システムを堅牢化するために kernel.yama.ptrace_scope を 2 (管理者限定) や 3 (ptrace を禁止) に設定することを検討してください。

hidepid

警告:
  • これは、サンドボックスと Xorg 内で実行するアプリケーションなど、特定のアプリケーションで問題を発生させる場合があります (回避策を見てください)。
  • systemd > 237.64-1 を使用している場合、これは D-Bus、Polkit、PulseAudio、そして bluetooth で問題を発生させます。

カーネルには、proc ファイルシステムを hidepid= オプションと gid= オプションを使ってマウントすることで、他のユーザのプロセス (通常、/proc でアクセス可能) を非特権ユーザから秘匿する機能があります。これらのマウントオプションは https://docs.kernel.org/filesystems/proc.html でドキュメント化されています。

これにより、侵入者が動作中のプロセスの情報 (特権で動作しているデーモンがあるか、他のユーザが機密情報を扱うプログラムを実行しているか、他のユーザがプログラムを実行しているか) を得る作業を複雑化し、ユーザが特定のプログラムを実行しているかどうかを知るのを不可能にし (ただし、そのプログラムがそれ自体の挙動で存在を他者に知られることがないとする)、さらに、貧弱に書かれたプログラムが機密情報をプログラム引数を介して渡したとしてもローカルの盗聴者から守られます。

proc ユーザーとグループ#システムグループ#グループ (filesystem パッケージによって提供されています) は、他のユーザのプロセス情報を得ることのできるユーザのホワイトリストとして機能します。ユーザやサービスが自身以外の /proc/<pid> ディレクトリにアクセスする必要がある場合、そのユーザまたはサービスをproc グループに追加してください。

例えば、プロセスの情報を proc グループに属さない他のユーザから隠すには: 

/etc/fstab
proc	/proc	proc	nosuid,nodev,noexec,hidepid=2,gid=proc	0	0

ユーザのセッションを正しく動作させるために、systemd-logind を例外として追加する必要があります: 

/etc/systemd/system/systemd-logind.service.d/hidepid.conf
[Service]
SupplementaryGroups=proc

モジュールのロードを制限する

デフォルトの Arch カーネルは CONFIG_MODULE_SIG_ALL が有効で、linux パッケージの一部としてビルドされた全てのカーネルモジュールに署名します。これにより、カーネルは有効なキーで署名されたモジュールだけをロードするように制限できます。実際、これはローカルでコンパイルされた、もしくは virtualbox-host-modules-arch などのパッケージによって提供された、ツリー外のモジュールは全てロードできないことを意味します。

カーネルモジュールの読み込みは module.sig_enforce=1 カーネルパラメータを設定することで制限することができます。詳細はカーネルドキュメントで見られます。

kexec を無効にする

Kexec は、現在実行中のカーネルを置き換えることを可能にします。 

/etc/sysctl.d/51-kexec-restrict.conf
kernel.kexec_load_disabled = 1
ヒント: kexec は linux-hardened でデフォルトで無効になっています。

カーネルロックダウンモード

Linux 5.4 から、オプションのロックダウン機能がカーネルに追加されました。これは、UID 0 (root) とカーネルの間の境界を強化することを目的としています。この機能を有効にすると、ハードウェアやカーネルへの低レベルなアクセスに依存している一部のアプリケーションは動作しなくなる可能性があります。

ロックダウンを使用するには、LSM が初期化され、ロックダウンモードが設定されている必要があります。

公式にサポートされているカーネルは全て LSM を初期化しますが、ロックダウンモードを強制しません。

ヒント: 有効化されている LSM は cat /sys/kernel/security/lsm を実行することで確認することができます。

ロックダウンには2つの動作モードがあります:

  • integrity: ユーザーランドが実行中のカーネルを変更できるカーネル機能 (kexec、bpf) は無効化されます。
  • confidentiality: ユーザーランドがカーネルから機密情報を抽出するためのカーネルの機能も無効化されます。

特定の脅威モデルで指示がない限り、integrity を使用することが推奨されます。

実行時にカーネルのロックダウンを有効にするには、以下を実行してください: 

# echo mode > /sys/kernel/security/lockdown

起動時にカーネルのロックダウンを有効にするには、lockdown=mode カーネルパラメータを使用してください:

ノート:
  • カーネルロックダウンを実行時に無効化することはできません。
  • カーネルロックダウンは、ハイバネートを無効化します。

kernel_lockdown(7) も参照してください。

Linux Kernel Runtime Guard (LKRG)

LKRG (lkrg-dkmsAUR) は、カーネルの整合性チェックとエクスプロイト行為の検出を行うカーネルモジュールです。

アプリケーションのサンドボックス化

ノート: 標準の Arch カーネルではユーザー名前空間の CONFIG_USER_NS が設定されていないため、特定のサンドボックス機能がアプリケーションから使えない場合があります。linux-hardened パッケージでは有効になっていますが、非特権での使用はデフォルトで無効になっています。kernel.unprivileged_userns_clone の sysctl を 1 に設定することで使用できるようになりますが、ローカルの権限昇格を引き起こす可能性が高くなるので注意してください。
警告: linux (5.1.8 およびそれ以降)、linux-lts (4.19.55-2 およびそれ以降)、linux-zen (5.1.14.zen1-2 およびそれ以降) においては、kernel.unprivileged_userns_clone sysctl が 0 に設定されていない限り、非特権ユーザの名前空間の利用 (CONFIG_USER_NS_UNPRIVILEGED) がデフォルトで有効化されています。これはローカルの特権昇格の攻撃対象領域を大幅に増加させるので、これを手動で無効化するか linux-hardened カーネルを使用することが推奨されます。詳細は FS#36969 を見てください。

Firejail

Firejail はアプリケーションやサーバーをサンドボックス化するためのシンプルで使いやすいツールです。Firejail はサーバーだけでなくブラウザなどのインターネットに接続するアプリケーションでも使うことができます。

bubblewrap

bubblewrap は Flatpak から開発された setuid サンドボックスアプリケーションです。Firejail よりもリソースの消費力が少なく抑えられています。ファイルパスのホワイトリストなどの機能を欠いていますが、バインドマウントやユーザー/IPC/PID/ネットワーク/cgroup 名前空間の作成ができ、簡単なサンドボックスから 複雑なサンドボックス まで自在に使うことが可能です。

chroot

手動で chroot 監獄を構築する方法もあります。

Linux Containers

他の手段 (KVM や Virtualboxのような完全仮想化を除く) よりも強力な分離が必要なときは Linux Containers を選択するのもよいでしょう。LXC は仮想ハードウェアを使って擬似的な chroot で既存のカーネル上で動作します。

他の仮想化手段

VirtualBox, KVM, Xen などの完全な仮想化マシンを使うことでもセキュリティを向上させることができます。危険なアプリケーションを実行したり危険なウェブサイトを開いたりするときに役に立つでしょう。

ネットワークとファイアウォール

ファイアウォール

標準の Arch カーネルは Netfilter の iptables を使用する能力がありますが、デフォルトでは有効になっていません。公式リポジトリから iptables をインストールして、有効にし、ファイアウォールを設定することが強く推奨されます。

カーネルパラメータ

ネットワークに影響を与えるカーネルパラメータは sysctl を使って設定できます。設定方法は sysctl#TCP/IP スタックの防御 を見て下さい。

SSH

SSH 鍵を必要としない Secure Shell を使うのは避けましょう。これは総当たり攻撃を防ぎます。また、Fail2ban や Sshguard はログを監視して iptables ルールを書き込む方式の保護を提供しますが、攻撃者がアドレスを識別して管理者からのパケットのように偽装することができるため、サービスの妨害が行われる危険性があります。

二段階認証によって認証を強化することができます。Google Authenticator はワンタイムパスコード (OTP) を使用する二段階認証方式を提供します。

root ログインを拒否するのは、侵入追跡と root アクセス前のセキュリティレイヤを追加するという両方の面でグッドプラクティスです。

DNS

DNSSEC や DNSCrypt を見て下さい。

プロキシ

プロキシはアプリケーションとネットワークの間に挟まる追加レイヤーとして使われ、信頼できないソースからのデータをサニタイズします。少ない権限でプロキシを動作させることで、エンドユーザー権限で複雑なアプリケーションを実行するよりも攻撃対象を小さくすることができます。

例えば glibc の中に実装されている DNS リゾルバを考えてみてください。(root で実行することもある) アプリケーションにリンクされている DNS リゾルバにバグが存在した場合、リモートコード実行につながる危険があります。dnsmasq などの DNS キャッシュサーバーをインストールしてプロキシとして使うことで問題を防ぐことが可能です [6]。

SSL 証明書の管理

サーバーサイドの SSL 証明書の管理については OpenSSL や Network Security Services (NSS) を参照してください。また、関連する Let’s Encrypt プロジェクトも見てください。

デフォルトのインターネット SSL 証明書のトラストチェーンは ca-certificates パッケージによって提供されています。Arch はデフォルトで信頼しても問題ないとされる証明書を提供しているソース (例: ca-certificates-cacertAUR, ca-certificates-mozilla) に依存しています。

デフォルトの証明書を変えたいと思うことがあるかもしれません。例えば、ニュース を読んで証明書を信頼しないようにしたい場合 (ソースのプロバイダーによって無効になるのを待てない場合)、Arch のインフラを使うことで簡単に設定できます:

  1. .crt 形式の証明書を入手してください (例: view, download; 既存のルート認証局の場合、システム内にあるはずです)。
  2. /etc/ca-certificates/trust-source/blacklist/ にコピーしてください。
  3. root で update-ca-trust を実行してください。

お好きなブラウザを開いて信頼できないサイトとして表示されれば、ブラックリストが上手く機能しています。

物理セキュリティ

ノート: リモート攻撃からコンピュータを守りたいだけの場合はこのセクションは無視してかまいません。

十分な時間とリソースさえあればコンピュータへの物理的なアクセスは root アクセスになります。しかしながら、十分な防御策を張ることで実用的で高いレベルのセキュリティを得ることができます。

攻撃者は悪意のある IEEE 1394 (FireWire), Thunderbolt, PCI Express デバイスを取り付けることでメモリーへの完全なアクセスを手に入れることができ、次に起動した時には簡単にコンピュータの完全なコントロールを手中に収めることができます [7]。これを防ぐためにできることは限られており、悪意のあるファームウェアをドライブに書き込むなどハードウェア自体の改変に対処することは不可能です。ただし、攻撃者の大部分にはこうした知識がなく実行されることはほとんどありません。

ディスク暗号化はコンピュータが盗まれた場合にデータへのアクセスを防止しますが、あなたが次にログインしたときにデータを取得するために悪意のあるファームウェアが能力のある攻撃者によってインストールされる可能性があります。

BIOS をロックダウンする

BIOS にパスワードを追加することによってリムーバブルメディアから誰かが起動する (これはコンピュータへの root アクセスと基本的に同義です) のを予防します。使用しているドライブがブートの順番で一番最初に来ることを確認して、可能であれば他のドライブのブートを無効にしてください。

ブートローダー

ブートローダー を保護することは非常に重要です。保護されていないブートローダは、例えば init=/bin/sh を設定することでログインの制限を回避することができます。カーネルパラメータ でシェルに直接ブートするようにします。

Syslinux

Syslinux はブートローダーのパスワード保護をサポートしています。メニューのアイテムごとにパスワードを設定したり、ブートローダー全体にパスワードの保護を設定することが可能です。

GRUB

GRUB はブートローダのパスワードもサポートしています。詳しくは GRUB メニューのパスワード保護 を参照してください。暗号化 /boot もサポートしていますが、これはブートローダコードの一部だけを暗号化しないままにしています。GRUB の設定、カーネル、initramfs は暗号化されています。

セキュアブート

セキュアブート は UEFI の機能で、コンピュータが起動するファイルの認証を可能にするものです。これは、起動パーティション内のファイルを置き換えるような、いくつかの 悪意あるメイド攻撃 を防止するのに役立つ。通常、コンピュータにはベンダー (OEM) によって登録されたキーが付属しています。しかし、これを取り外して、コンピュータを「セットアップモード」にし、ユーザーが自分のキーを登録・管理できるようにすることができます。

セキュアブートのページでは、using your own keys によってセキュアブートを設定する方法を案内しています。

トラステッドプラットフォームモジュール（TPM）

TPM は、暗号鍵が埋め込まれたハードウェア・マイクロプロセッサです。これは、最近のほとんどのコンピュータの基本的な信頼性の根源を形成し、ブートチェーンのエンドツーエンドの検証を可能にします。内部スマートカードとして使用したり、コンピュータ上で動作するファームウェアを証明したり、改ざん防止とブルートフォース耐性のあるストアにユーザーがシークレットに挿入することができます。

リムーバブル フラッシュ ドライブ上のブートパーティション

ブートパーティションをフラッシュドライブに置き、それがないとシステムが起動しないようにする、というのはよくあるアイデアです。このアイデアの支持者はしばしば ディスク暗号化 を併用し、ブートパーティションに置かれた encryption headers を使っている人もいます。

この方法は encrypting /boot と統合することも可能です。

自動ログアウト

Bash または Zsh を使っている場合、TMOUT によってタイムアウトによるシェルからの自動ログアウトを設定できます。

例えば、以下は仮想コンソールから自動でログアウトします (X11 のターミナルエミュレータからはログアウトしません): 

/etc/profile.d/shell-timeout.sh
TMOUT="$(( 60*10 ))";
[ -z "$DISPLAY" ] && export TMOUT;
case $( /usr/bin/tty ) in
	/dev/tty[0-9]*) export TMOUT;;
esac

(X のコンソールも含めて) 全ての Bash/Zsh プロンプトでタイムアウトさせたい場合は、次を使って下さい: 

$ export TMOUT="$(( 60*10 ))";

シェルで何かコマンドが動作している間はこのタイムアウトは動作しないので注意してください (例: SSH セッションや TMOUT をサポートしていない他のシェル)。しかしながら固まった GDM/Xorg を root で再起動するのに VC を使っているような場合は、とても有用です。

不正なUSBデバイスから保護する

Usbguard は、デバイスの属性に基づく基本的なホワイトリストおよびブラックリスト機能を実装することで、不正な USB デバイス (別名 BadUSB, PoisonTap または LanTurtle) からコンピューターを保護できるソフトウェアフレームワークです。

揮発性データの収集

電源が入っているコンピュータは、volatile data collection に対して脆弱である可能性があります。コンピュータの電源を入れる必要がない時や、コンピュータの物理的な安全性が一時的に損なわれる場合（例:セキュリティチェックポイントを通過する時）には、コンピュータの電源を完全に切ることがベストプラクティスです。

パッケージ

パッケージの認証

パッケージの署名が適正に使われていないと パッケージマネージャへの攻撃 が考えられ、さらに 適切な署名システム を使っているパッケージマネージャにも影響を与える可能性があります。Arch はデフォルトでパッケージの署名を使用しており5つの信頼されたマスターキーによる web of trust を使っています。詳しくは Pacman-key を見て下さい。

アップグレード

定期的に システムのアップグレード を行うことが重要です。

脆弱性アラートの確認

National Vulnerability Database が提供する Common Vulnerabilities and Exposure (CVE) Security Alert の更新を購読し、NVD Download webpage で見つけてください。Arch Linux Security Tracker は Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG), CVE データセットを表形式でまとめた、特に有用なリソースです。ツール arch-audit は実行中のシステムに影響を与える脆弱性をチェックするために使われます。グラフィカルなシステムトレイである arch-audit-gtk も使うことができます。Arch Security Teamも参照してください。

特にメインレポジトリや AUR 以外の手段でソフトウェアをインストールしている場合は、あなたが使っているソフトウェアのリリース通知を購読することも検討すべきです。いくつかのソフトウェアには、セキュリティに関する通知を受け取るために購読できるメーリングリストがあります。ソースコードホスティングサイトはしばしば新しいリリースの RSS フィードを提供しています。

パッケージの再ビルド

攻撃対象領域を減らす手段として、パッケージをリビルドし、不要な関数や機能を削除することができます。例えば、bzip2 は CVE-2016-3189 を回避するために bzip2recover を使わずにリビルドすることが可能です。カスタムハードニングフラグは、手動またはラッパーを介して適用することもできます。

フラグ 目的
-D_FORTIFY_SOURCE=2 ランタイムバッファオーバーフローの検出
-D_GLIBCXX_ASSERTIONS C++ の文字列とコンテナのランタイム境界チェック
-fasynchronous-unwind-tables バックトレースの信頼性向上
-fexceptions テーブルベースのスレッドキャンセルを有効にする
-fpie -Wl,-pie 実行可能ファイルに対する完全な ASLR
-fpic -shared 共有ライブラリのテキスト再配置を行わない
-fplugin=annobin ハードニング品質管理用データの作成
-fstack-clash-protection スタックオーバーフロー検出の信頼性向上
-fstack-protector or -fstack-protector-all スタックスマッシュプロテクター
-fstack-protector-strong 同様に
-g デバッグ情報を生成する
-grecord-gcc-switches デバッグ情報にコンパイラのフラグを格納する
-mcet -fcf-protection 制御フローの完全性保護
-O2 推奨される最適化
-pipe 一時ファイルを回避し、ビルドを高速化します。
-Wall 推奨されるコンパイラの警告
-Werror=format-security 安全でない可能性のあるフォーマット文字列の引数を拒否する
-Werror=implicit-function-declaration 関数プロトタイプの欠落を却下する
-Wl,-z,defs アンダーリンクの検出と拒否
-Wl,-z,now 遅延バインディングを無効にする
-Wl,-z,relro 移設後の読み出し専用セグメント

参照

「https://wiki.archlinux.jp/index.php?title=セキュリティ&oldid=38898」から取得