Docker的AppArmor配置問題歸總

weixin_33912445發表於2017-07-03

Docker可以通過AppArmor或者SELinux進行訪問控制,既然是訪問控制的過程中難免需要進行對其的配置。此專案是通過AppArmor進行防護的,在配置時遇到了許多問題,在此記錄。

1.如何呼叫AppArmor進行Docker的許可權控制

這一項在官方文件中有記載。在啟動或者執行docker通過引數"--security-opt"加入訪問控制的配置檔案。--security-opt的預設引數為docker-default。docker-default並非一個實際的配置檔案,而是由執行時由GO語言執行的配置模板自動生成並寫入AppArmor快取。(Docker versions 1.13.0 and later)

2.為Docker配置許可權檔案

由於是為docker的container進行安全配置,我們將配置檔案放置於/etc/containers/目錄下。為方便管理配置檔案的命名與配置名同名。官方列舉了一個Nginx 的docker配置檔案
#include <tunables/global>

profile docker-nginx flags=(attach_disconnected,mediate_deleted) {
  #include <abstractions/base>

  network inet tcp,
  network inet udp,
  network inet icmp,

  deny network raw,

  deny network packet,

  file,
  umount,

  deny /bin/** wl,
  deny /boot/** wl,
  deny /dev/** wl,
  deny /etc/** wl,
  deny /home/** wl,
  deny /lib/** wl,
  deny /lib64/** wl,
  deny /media/** wl,
  deny /mnt/** wl,
  deny /opt/** wl,
  deny /proc/** wl,
  deny /root/** wl,
  deny /sbin/** wl,
  deny /srv/** wl,
  deny /tmp/** wl,
  deny /sys/** wl,
  deny /usr/** wl,

  audit /** w,

  /var/run/nginx.pid w,

  /usr/sbin/nginx ix,

  deny /bin/dash mrwklx,
  deny /bin/sh mrwklx,
  deny /usr/bin/top mrwklx,


  capability chown,
  capability dac_override,
  capability setuid,
  capability setgid,
  capability net_bind_service,

  deny @{PROC}/* w,   # deny write for all files directly in /proc (not in a subdir)
  # deny write to files not in /proc/<number>/** or /proc/sys/**
  deny @{PROC}/{[^1-9],[^1-9][^0-9],[^1-9s][^0-9y][^0-9s],[^1-9][^0-9][^0-9][^0-9]*}/** w,
  deny @{PROC}/sys/[^k]** w,  # deny /proc/sys except /proc/sys/k* (effectively /proc/sys/kernel)
  deny @{PROC}/sys/kernel/{?,??,[^s][^h][^m]**} w,  # deny everything except shm* in /proc/sys/kernel/
  deny @{PROC}/sysrq-trigger rwklx,
  deny @{PROC}/mem rwklx,
  deny @{PROC}/kmem rwklx,
  deny @{PROC}/kcore rwklx,

  deny mount,

  deny /sys/[^f]*/** wklx,
  deny /sys/f[^s]*/** wklx,
  deny /sys/fs/[^c]*/** wklx,
  deny /sys/fs/c[^g]*/** wklx,
  deny /sys/fs/cg[^r]*/** wklx,
  deny /sys/firmware/** rwklx,
  deny /sys/kernel/security/** rwklx,
}

其中配置標籤需要以profile <name>的方式進行,以便通過--security-opt引數的形式被呼叫。flags=(attach_disconnected)似乎是必要的。
attach_disconnected,設定配置檔案的名稱解析為相對路徑,不設定無法找到對應的配置。
mediate_deleted,中介刪除?

為Docker內應用配置許可權檔案

上述方式可以對Docker內檔案的使用許可權進行配置。但是,在對Docker內某一應用進行配置時卻是區別於原本AppArmor對主機應用的配置。其許可權配置主要是通過子配置實現的。
比如對/usr/bin/python3.5限制不允許訪問/etc資料夾下的內容。
#include <tunables/global>
profile docker-profile flags=(attach_disconnected,mediate_deleted) {
#include <abstractions/base>
network,
capability,
file,
umount,
...
/usr/bin/python3.5 cx -> python_profile,
profile python_profile flags=(mediate_deleted,attach_disconnected) {
file,
deny /etc/** rwklx,
deny /etc/ rwklx,
network inet tcp,
}
...
}
AppArmor對於Docker內應用的限制似乎只能通過黑名單的形式,即使用允許file許可權即允許所有docker內檔案的許可權。之後只能通過deny逐一禁止。

相關文章