Docker的AppArmor配置问题归总

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

profile docker-nginx flags=(attach_disconnected,mediate_deleted) {
  #include 

  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//** 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 的方式进行,以便通过--security-opt参数的形式被调用。flags=(attach_disconnected)似乎是必要的。
attach_disconnected,设定配置文件的名称解析为相对路径,不设置无法找到对应的配置。
mediate_deleted,中介删除?

为Docker内应用配置权限文件

上述方式可以对Docker内文件的使用权限进行配置。但是,在对Docker内某一应用进行配置时却是区别于原本AppArmor对主机应用的配置。其权限配置主要是通过子配置实现的。
比如对/usr/bin/python3.5限制不允许访问/etc文件夹下的内容。
#include
profile docker-profile flags=(attach_disconnected,mediate_deleted) {
#include
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逐一禁止。

你可能感兴趣的:(Docker的AppArmor配置问题归总)