シンプルさには代償が伴う (例:アクセス制御)

Linuxのファイルアクセス制御によるセキュリティ確保。

/*************************************************************************************/
LinuxにはSELinuxとAppArmorというのがあるらしいが、これは何か? (->Gemini)
SELinuxとAppArmorは、一言で言うと「万が一、管理者権限(root)を奪われても、被害を最小限に食い止めるための強力な防壁」です。
通常のLinuxの権限管理(パーミッション)だけでは防げない攻撃に対処するための仕組みで、これらはMAC(強制アクセス制御)と呼ばれます。カーネルモジュールが機能を提供している。

## 1. なぜこれらが必要なのか?
通常のLinux(DAC:任意アクセス制御)では、「ファイル所有者」がアクセス権を決めます。しかし、もし脆弱性のあるプログラムを root(最高権限者) として動かしていた場合、そのプログラムがハックされると、攻撃者はシステム内のあらゆるファイルにアクセスできてしまいます。

SELinuxやAppArmorがあると:
プログラムごとに「このアプリは設定ファイルは読めるが、パスワードファイルには触れない」「ネットワーク通信はできるが、書き込みは禁止」といった「型」や「プロファイル」を強制します。たとえroot権限を奪われても、あらかじめ許可された行動以外は一切できなくなります。

## 2. SELinux と AppArmor の違い
どちらも目的は同じですが、アプローチが異なります。
| 特徴               | SELinux (Security-Enhanced Linux)                | AppArmor (Application Armor)         |
| ------------------ | ------------------------------------------------ | ------------------------------------ |
| 主な採用ディストリ | RHEL, CentOS, Fedora, Android                    | Ubuntu, Debian, openSUSE             |
| 制御の対象         |「ラベル」(すべてのファイルやプロセスにタグを貼る)|「パス」(ファイルの場所を指定する)    |
| 学習コスト         | 高い(設定が複雑で、管理が難しい)                 |低い(設定ファイルが読みやすく、直感的)|
| 柔軟性・厳格さ     | 非常に高い(システム全体を細かく制御)             |中程度(特定のアプリを保護するのが得意)|

### SELinux の特徴
* 米国家安全保障局(NSA)が開発に関わった、非常に厳格な仕組みです。
* ファイル一つひとつに「これはウェブサーバー用」「これはログ用」というセキュリティコンテキスト(ラベル)を付与します。
* 「ラベルAのプロセスは、ラベルBのファイルにしかアクセスできない」というルールで縛ります。
* 設定を間違えると、正規のプログラムすら動かなくなることが多いため、初心者はまず「無効化(disable)」したくなるという「Linuxあるある」の元凶でもあります。

### AppArmor の特徴
* 「設定のしやすさ」を重視しています。
* `/usr/sbin/nginx` は `/var/www/` 以下にアクセスできる、といった具合にディレクトリの場所(パス)ベースで制限をかけます。
* プロファイル(設定ファイル)がテキスト形式で人間にも読みやすいため、トラブルシューティングが比較的楽です。

## 結局どっちがいいの?
基本的には「使っているOSのデフォルトに従う」のが正解です。
* Ubuntu/Debian系を使っているなら、すでに AppArmor が裏であなたを守っています。
* RHEL/Fedora系を使っているなら、SELinux がガードを固めています。
これらは競合するため、通常は1つのシステムで両方を同時に動かすことはありません。

### 豆知識
Androidスマホも中身はLinuxベースですが、実は **SELinux** が採用されています。アプリが勝手にカメラを起動したり、他のアプリのデータを盗んだりできないのは、このSELinuxの強力な制限があるおかげでもあります。

現在お使いのLinuxディストリビューションがあれば、そのOSで「今の設定状態を確認するコマンド」をお教えしましょうか?

/*************************************************************************************/
現在使っているディストリビューションはSlackware。
おっと、Slackwareをお使いですか!非常に硬派で、Linuxの仕組みを深く知るには最高の選択ですね。
結論から言うと、SlackwareはUbuntu(AppArmor)やRed Hat(SELinux)とは異なり、デフォルトではどちらも有効になっていない(あるいは非常に限定的)という特徴があります。

## Slackwareにおけるセキュリティの考え方
Slackwareの哲学は「KISS (Keep It Simple, Stupid)」です。複雑な自動設定ツールを避け、システム管理者が直接ファイルを制御することを重視します。

* SELinux/AppArmorの標準搭載: 公式の標準インストールでは、これらは「標準でオン」にはなっていません。カーネルレベルでサポートはされていますが、ポリシー(どのアプリが何をしていいかというルール)を自分で書くのは非常に骨が折れます。
* 伝統的な権限管理: Slackwareユーザーは、SELinuxのような複雑な仕組みに頼るよりも、適切なユーザー権限(Groups/Permissions)の管理や、不要なサービスの停止によってシステムを堅牢に保つ傾向があります。

## 状態を確認してみましょう
ご自身の環境で、これらがどうなっているか確認するコマンドを紹介します。

### 1. SELinux の状態確認
以下のコマンドを打ってみてください。
$ sestatus
もし「command not found」と出れば、ツール自体がインストールされていません。もし入っていれば `Disabled` と表示されるはずです。

### 2. AppArmor の状態確認
$ aa-status
こちらも同様に、標準のSlackwareでは「そんなコマンドはない」と言われる可能性が高いです。

## それでも導入したい場合は?
もしSlackwareでこれらを使いたい場合、いくつかの道があります:
1. SlackBuilds.org (SBo) を利用する:
AppArmorなどはSBoにスクリプトが存在することがありますが、カーネルの再構築が必要になる場合もあり、難易度は高めです。
2. LSM (Linux Security Modules) の確認:
カーネルがどのセキュリティモジュールをサポートしているかは、以下のコマンドで確認できます。
$ cat /sys/kernel/security/lsm

### Slackwareユーザーへのアドバイス
Slackwareでセキュリティを強化したいなら、まずは 「実行するサービスを最小限にする」 ことと、「ファイアウォール(iptables/nftables)を適切に設定する」 ことが定石です。SELinuxは「設定ミスで自分が締め出される」リスクがあるため、まずは仮想環境などで実験することをお勧めします。

次は、Slackwareでファイアウォール(iptables)の現在のルールを確認する方法などをお伝えしましょうか?

/*************************************************************************************/
Slackwareにおけるセキュリティの考え方は、昔からのUnixやFreeBSDと同じか?
その通りです!おっしゃる通り、Slackwareのセキュリティ哲学は、モダンなLinuxディストリビューション(FedoraやUbuntu)よりも、伝統的なUnixやFreeBSDの精神に極めて近いです。
「システムが自動的に守ってくれる」のではなく、「管理者が仕組みを理解し、正しく設定することで守る」というスタンスですね。

## Slackwareと伝統的Unix/FreeBSDの共通点
### 1. 「シンプルさ」こそが安全(KISS原則)
複雑なセキュリティレイヤー(SELinuxなど)は、設定ミスがかえって脆弱性を生んだり、トラブルシューティングを困難にしたりします。SlackwareやFreeBSDは、「設定ファイルがシンプルであれば、管理者がミスに気づきやすい」と考えます。

### 2. 最小主義(Minimalism)
「使わないサービスは動かさない」のが鉄則です。
* Slackware: `/etc/rc.d/` 以下のスクリプトに実行権限を与えなければサービスは起動しません。
* FreeBSD: `rc.conf` で明示的に `_enable=”YES”` と書かない限り動きません。
どちらも「デフォルトで何でもオープン」な状態を嫌います。

### 3. 特権の分離とパーミッション
SELinuxのような「ラベル」による制御ではなく、古典的な UID/GID(ユーザーID/グループID) と ファイルパーミッション による制御を徹底します。
* 特定のデーモンは専用のユーザーで動かす。
* 重要なディレクトリの所有権を厳格に管理する。
これらUnixの基本作法が、最大の防御壁であるという考え方です。

## FreeBSDとの細かな違い
思想は似ていますが、実装には少し違いがあります。
| 機能             | Slackware (Classic Linux)    | FreeBSD                          |
| ---------------- | ---------------------------- | -------------------------------- |
| ベース           | Linuxカーネル + GNUツール    | BSDカーネル + 独自ユーザーランド |
| 隔離技術         | chroot (伝統的)              | Jails (より強力な仮想化・隔離)   |
| パッチ管理       | ソースまたはバイナリ手動更新 | `freebsd-update` や Ports/Pkg    |
| セキュリティ拡張 | 必要ならLSMを追加可能        | Capsicum や MACフレームワーク    |

## Slackwareで「Unixらしく」守るための3ステップ
もしSlackwareを堅牢にしたいなら、以下の「伝統的な手法」を極めるのが一番の近道です。
1. `/etc/rc.d/` の整理:
不要なネットワークサービス(inetd, portmap, etc…)が動いていないか確認し、実行権限を外します(`chmod 644 /etc/rc.d/rc.inetd` など)。
2. TCP Wrappers の活用:
`/etc/hosts.allow` と `/etc/hosts.deny` を使い、IPアドレスベースでアクセス制限をかけます。これは非常にUnixらしい枯れた技術です。
3. ログの監視:
`/var/log/messages` や `secure` を定期的にチェックし、不審な挙動がないか自分の目で確認します。

Slackwareは「OSに管理される」のではなく「OSを管理する」楽しみを教えてくれます。
次は、Slackwareで具体的にどのサービスがポートを開けて待機しているか、Unix流に確認するコマンド(`netstat` や `lsof`)の使い方を紹介しましょうか?

/*************************************************************************************/

 

参考情報:
シンプルさには代償が伴う理由
https://www.youtube.com/watch?v=R-gJ7aJJnqg

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です