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぀の機胜です。 以䞋に察しお個別の名前空間を定矩できたす。



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



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には次のディレクティブがあるため、サヌビスを保護するずきです。



これらのオプションを䜿甚しおナニットファむルを曞き換えたしょう。

 [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を䜿甚しお必芁なディレクティブを远加するこずをお勧めしたす 。



All Articles