systemdでデーモンを分離するか、「これにはDockerは必要ありません！」

最近、かなり多くの人が、コンテナ内で潜在的に安全でないアプリケーションをロックするためだけにコンテナ仮想化を使用しているのを見てきました。 原則として、彼らはその普及のためにこれにDockerを使用し、より良いことは知りません。 実際、多くのデーモンは最初にrootとして起動され、その後、特権を下げるか、マスタープロセスが低い特権で処理プロセスを生成します。 そして、ルートからのみ機能するものがあります。 最大の権限でアクセスを許可するデーモンに脆弱性が見つかった場合、すでにすべてのデータをダウンロードしてウイルスを残している侵入者を検出することはあまり快適ではありません。
Dockerや他の同様のソフトウェアによって提供されるコンテナー化は、この問題を本当に軽減しますが、新しいものももたらします。各デーモンのコンテナーを作成し、変更されたファイルの安全を守り、ベースイメージを更新する必要があり、コンテナー自体は多くの場合、必要な異なるOSに基づいていますディスクに保存しますが、一般的には特に必要ありません。 コンテナが必要ない場合、アプリケーションがDocker Hubで必要な方法でビルドされておらず、バージョンが非推奨であり、SELinuxとAppArmorが複雑すぎると思われる場合は、環境で実行したいが、同じものを使用する場合Dockerが使用する分離はありますか？

能力

通常のユーザーとルートの違いは何ですか？ rootがネットワークを管理し、カーネルモジュールをロードし、ファイルシステムをマウントし、すべてのユーザーのプロセスを強制終了でき、通常のユーザーはそのような機会を奪われているのはなぜですか？ すべての機能 、つまり特権を管理するためのツールです。 これらのすべての特権は、デフォルトでUID 0（つまり、root）のユーザーに与えられ、通常のユーザーにはそれらのいずれもありません。 特権は、付与または削除することができます。 たとえば、通常のpingコマンドではRAWソケットを作成する必要がありますが、これは通常のユーザーに代わって行うことはできません。 これまで、pingにはSUIDフラグが設定されていました。これは単にスーパーユーザーの代わりにプログラムを実行していましたが、現在のすべてのディストリビューションではCAP_NET_RAW機能が設定され、どのアカウントからでもpingを実行できます。
libcapからgetcapコマンドを使用して、ファイルのインストール済み機能のリストを取得できます。

 % getcap $(which ping) /usr/bin/ping = cap_net_raw+ep 

ここでpフラグは許可されます。 アプリケーションには指定された機能を使用する機能があり、 eは効果的です -アプリケーションはそれを使用します。また、 iフラグもあります- 継承可能で、 execve()関数が呼び出されたときに機能リストを保存できます。
機能は、FSレベルと、個別のプログラムストリームの両方で設定できます。 ローンチ以来利用できなかった機能を取得することは不可能です。 特権を減らすことはできますが、増やすことはできません。
セキュアビットもあります。3つあります。KEEP_CAPSを使用すると、setuidを呼び出すときに機能を保存できます。NO_SETUID_FIXUPは、setuidを呼び出すときに機能の再構成を無効にし、NOROOTは、suidプログラムを実行するときに追加の特権を発行することを禁止します。

名前空間

名前空間にアプリケーションを配置する機能は、Linuxカーネルのもう1つの機能です。 以下に対して個別の名前空間を定義できます。

• ファイルシステム
• UTS（ホスト名）
• System V IPC（プロセス間通信）
• ネットワーク
• PID
• ユーザー

たとえば、アプリケーションを別のネットワークスペースに配置すると、ホストから見えるネットワークアダプターを見ることができなくなります。 ファイルシステムでも同じことができます。

systemd

幸いなことに、systemdは、アプリケーションを分離し、権利を区別するために必要なすべてをサポートしています。
これらの機能を使用しますが、最初にアプリケーションに必要な権利について少し考えます。
それでは、悪魔とは何ですか？ 通常、スーパーユーザーの権限が必要とされないものがあり、それらは1024未満のポートをリッスンするためだけに使用します。このようなプログラム機能CAP_NET_BIND_SERVICEを発行するだけで十分です。 setcapコマンドを使用して、ファイルに機能をインストールできます。 実験的な「サービス」として、nmapのncatを使用します。これにより、必要な人にシェルアクセスが提供されます。さらに悪いことは想像できません。

 % sudo setcap CAP_NET_BIND_SERVICE=ep /usr/bin/ncat % getcap /usr/bin/ncat /usr/bin/ncat = cap_net_bind_service+ep 

nobodyユーザーに代わって、ポート81で必要なパラメーターを指定してncatを実行する最も単純なsystemdユニットを作成します。

 [Unit] Description=Vuln [Service] User=nobody ExecStart=/usr/bin/ncat --exec /bin/bash -l 81 --keep-open --allow ::1 

/etc/systemd/system/vuln.service保存し、通常のsudo systemctl start vulnを実行します。
私たちはそれに接続しています：

 % ncat ::1 81 whoami nobody 

うまくいきます！
このsystemdには次のディレクティブがあるため、サービスを保護するときです。

• CapabilityBoundingSet = -機能を制御します。 チルダ文字「〜」が最初の前にある場合、このパラメータで転送されたもののみを設定します。逆も同様です。
• SecureBits = -セキュリティビットを設定します。
• Capabilities = - 機能も管理しますが、FSレベルでファイルに記述された機能に利点があるため、実用的ではありません。
• ReadWriteDirectories =、ReadOnlyDirectories =、InaccessibleDirectories = -ファイルシステムの名前空間を管理します。 デーモン名前空間内でファイルシステムを再マウントして、指定されたディレクトリが読み取りと書き込みに使用できるようにするか、読み取り専用にするか、まったく使用できないようにします（空になります）。
• PrivateTmp = -名前空間内の独自のtmpfsに/ tmpおよび/ var / tmpを再マウントします。
• PrivateDevices = -/ devからデバイスへのアクセスを選択し、/ dev / null、/ dev / zero、/ dev / randomなどの標準デバイスへのアクセスのみを残します。
• PrivateNetwork = -単一のloインターフェイスで空のネットワーク名前空間を作成します。
• ProtectSystem = -/ usrと/ bootを読み取り専用モードでマウントします。引数「full」を渡すと、/ etcでも同じことが行われます。
• ProtectHome = -/ home、/ root、および/ run / userディレクトリにアクセスできないようにするか、「読み取り専用」パラメータを使用して読み取り専用モードで再マウントします
• NoNewPrivileges = -アプリケーションが追加の特権を受け取らないことを確認できます。 著者によると、これは対応する機能よりも強力です。
• SystemCallFilter = -seccompテクノロジーを使用してシステムコールをフィルタリングします。 これについては後で詳しく説明します。

これらのオプションを使用してユニットファイルを書き換えましょう。

 [Unit] Description=Vuln [Service] User=nobody ExecStart=/usr/bin/ncat --exec /bin/bash -l 81 --keep-open --allow ::1 CapabilityBoundingSet=CAP_NET_BIND_SERVICE InaccessibleDirectories=/sys PrivateTmp=true PrivateDevices=true ProtectHome=true ProtectSystem=full 

そのため、アプリケーションに1つの機能CAP_NET_BIND_SERVICEを付与し、個別の/ tmpおよび/ var / tmpを作成し、デバイスおよびホームディレクトリへのアクセスを選択し、読み取り専用モードで/ usr、/ bootおよび/ etcを再マウントし、個別にブロック/ sys、t .k。 典型的なデーモンがそこに到達する可能性は低く、これはすべてユーザーに代わって行われます。
CapabilityBoundingSetでは、suやsudoなどのsuid-applicationでさえ追加の機能を取得できないため、パスワードを知っていても、別のユーザーまたはルートに代わってアクセスすることはできません。 カーネルはsetuidおよびsetgid呼び出しを許可しません。

 % ncat ::1 81 python -c 'import pty; pty.spawn("/bin/bash")' #   pty,      sudo  su [nobody@valaptop /]$ sudo -i #  setuid()  setgid() sudo: unable to change to root gid: Operation not permitted sudo: unable to initialize policy plugin [nobody@valaptop /]$ ping #   capability cap_net_raw bash: /usr/sbin/ping: Operation not permitted [nobody@valaptop /]$ cd /home bash: cd: /home: Permission denied [nobody@valaptop /]$ ls -lad /home d--------- 2 root root 40 Nov 3 11:46 /home [nobody@valaptop tmp]$ ls -la /tmp total 4 drwxrwxrwt 2 root root 40 Nov 5 00:31 . drwxr-xr-x 19 root root 4096 Nov 3 22:28 .. 

2番目のタイプのデーモン、ルートとして実行され、特権を下げるデーモンについて考えてみましょう。 このアプローチは多くの目的で使用されます：スーパーユーザー（WebサーバーでTLSを使用するための秘密鍵など）からのみアクセス可能な機密ファイルの読み取り、非ルートフォークが侵害された場合に利用できないログの維持、および任意のアプリケーションのみUID（ssh-servers、ftp-servers）を変更します。 そのようなプログラムが分離されていない場合、起こりうる最悪の事態は、攻撃者がスーパーユーザーに代わってフルアクセスを取得することです。 rootに固有の機能の欠如により、彼はほとんど普通の非特権ユーザーになりますが、rootは、彼が読み取ることができる彼に属するファイルの束とともにrootのままです。そのため、キーを保管できるディレクトリがなく、読むべきではない設定ファイル：

 [Unit] Description=Vuln [Service] ExecStart=/usr/bin/ncat --exec /bin/bash -l 81 --keep-open --allow ::1 CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_SETUID CAP_SETGID NoNewPrivileges=yes InaccessibleDirectories=/sys InaccessibleDirectories=/etc/openvpn InaccessibleDirectories=/etc/strongswan InaccessibleDirectories=/etc/nginx ReadOnlyDirectories=/proc PrivateTmp=true PrivateDevices=true ProtectHome=true ProtectSystem=full 

ここでは、機能CAP_SETUIDおよびCAP_SETGIDを追加して、デーモンが権限を下げ、NoNewPrivilegesを使用して機能を増やせないようにし、読み取るべきでないディレクトリへのアクセスをブロックし、/ procへの読み取り専用アクセスを許可しますsysctlを使用できませんでした。 また、ルート全体を読み取り専用で一度にマウントし、プログラムが使用するディレクトリにのみ書き込み権限を付与することもできます。
/ etc / shadowファイルの権限を個別に確認する必要があります。 最新のディストリビューションでは、rootでも読めないため、CAP_DAC_OVERRIDE機能を使用して作業します。これにより、アクセス権を無視できます。

 % ls -la /etc/shadow ---------- 1 root root 1214  3 19:57 /etc/shadow 

設定を確認してください！

 python -c 'import pty; pty.spawn("/bin/bash")' #   pty [root@valaptop /]# whoami root [root@valaptop /]# ping #   capability cap_net_raw bash: /usr/sbin/ping: Operation not permitted [root@valaptop /]# cat /etc/shadow #  CAP_DAC_OVERRIDE cat: /etc/shadow: Permission denied [root@valaptop /]# cd /etc/openvpn bash: cd: /etc/openvpn: Permission denied [root@valaptop /]# /suid # SUID shell [root@valaptop /]# cat /etc/shadow #  -  shell,    cat: /etc/shadow: Permission denied 

残念ながら、systemdは（今のところ）PID名前空間を操作する方法を知らないため、ルートデーモンはルートとして実行されている他のプログラムを強制終了できます。
一般に、ここで終了することは可能です。機能と名前空間の設定はアプリケーションを分離するのに良い仕事をしますが、設定するのが素晴らしいもう一つのことがあります。

seccomp

Seccompテクノロジーは、プログラムが特定のシステムコールを行うことを防ぎ、実行しようとするとすぐに強制終了します。 seccompはかなり前に登場しましたが、2005年には、Chrome 20、vsftpd 3.0、およびOpenSSH 6.0のリリースにより、比較的最近使用され始めました。
seccompを使用するには、ブラックリストとホワイトリストの2つのアプローチがあります。 潜在的に危険なコールをブラックリストに登録することは、ホワイトよりも著しく単純なので、このアプローチがより頻繁に使用されます。 firejailプロジェクトは、デフォルトでプログラムが次のsyscallを実行することを禁止します（チルダはブラックリストモードを有効にします）：

 SystemCallFilter=~mount umount2 ptrace kexec_load open_by_handle_at init_module \ finit_module delete_module iopl ioperm swapon swapoff \ syslog process_vm_readv process_vm_writev \ sysfs_sysctl adjtimex clock_adjtime lookup_dcookie \ perf_event_open fanotify_init kcmp add_key request_key \ keyctl uselib acct modify_ldt pivot_root io_setup \ io_destroy io_getevents io_submit io_cancel \ remap_file_pages mbind get_mempolicy set_mempolicy \ migrate_pages move_pages vmsplice perf_event_open 

バージョン227より前のsystemdでは、seccompを使用するためにNoNewPrivileges = trueを設定する必要があるバグがあります。
ホワイトリストは次のようにコンパイルできます。

1. straceで必要なプログラムを実行します。
   

    % strace -qcf nginx 

   
   syscallsの大きなテーブルを取得します。
   

     time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 0.00 0.000000 0 24 read 0.00 0.000000 0 27 open 0.00 0.000000 0 32 close 0.00 0.000000 0 6 stat … 0.00 0.000000 0 1 set_tid_address 0.00 0.000000 0 4 epoll_ctl 0.00 0.000000 0 3 set_robust_list 0.00 0.000000 0 2 eventfd2 

   
   
2. それらをすべて書き換えて、 SystemCallFilterとして設定します。 ほとんどの場合、アプリケーションは次の理由でクラッシュします。 straceはすべての呼び出しを検出しませんでした。 監査デーモンのログでアプリケーションが終了した呼び出しの実行を確認します。
   

    type=SECCOMP msg=audit(1446730375.597:7943724): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=11915 comm="(nginx)" exe="/usr/lib/systemd/systemd" sig=31 arch=40000003 syscall=191 compat=0 ip=0xb75e5be8 code=0x0 

   必要なsyscallの番号は191です。 呼び出しテーブルを開き、この呼び出しの名前を番号で探します。
3. 許可された呼び出しに追加します。 転倒した場合、ポイント2に戻ります。

ヒントとコツ

captestコマンドを使用して、現在の特権とそれらを増やす可能性を確認できます。
filecapは、機能がインストールされたファイルのリストを表示します。
netcapを使用すると、少なくとも1つのソケットと1つの機能を持つ実行中のネットワークプログラムのリストを取得でき、 pscapはソフトウェアを実行しているネットワークだけでなく表示します。
アップグレード中にsystemdユニットを完全に編集してその変更を追跡する必要はありませんが、 systemctl editを使用して必要なディレクティブを追加することをお勧めします 。