배경
NFSv4 내보내기/공유의 경우 기본적으로 활성화된 root_squash 옵션은 NFS가 클라이언트의 루트를 익명 ID로 변경하도록 강제합니다. 이는 실제로 한 시스템의 루트 계정 소유권이 다른 시스템으로 마이그레이션되는 것을 방지하여 보안을 강화합니다.
Overlayfs를 사용하면 로컬의 투명한 파일 시스템을 다른 파일 시스템 위에 마운트할 수 있습니다. 불행히도 실제 사용자가 아닌 루트 사용자를 사용하여 기본 파일 시스템에 액세스하는 것처럼 보입니다. 적어도 그것이 내가 다음 실험에서 이끌어낸 결론이다.
NFS 공유에 Overlayfs를 마운트하는 이유는 무엇입니까? 신뢰도가 낮은 시스템이 공유 파일 시스템에 쓸 수 있는 척할 수 있도록 허용합니다.
테스트 설정
먼저 배포판에 맞게 NFS 커널 서버를 설치하십시오. 그런 다음 NFSv4만 내보내는지 확인하세요. (이 문제에는 중요하지 않을 수도 있지만 보안상 좋은 예방 조치입니다.)
$ sudo cat /proc/fs/nfsd/versions
-2 -3 +4 +4.1 +4.2
그렇지 않다면 을 살펴보고 /etc/nfs.conf설정하십시오 vers3=n.
그런 다음 희소 파일에 en Ext4 파일 시스템을 생성하고 이를 로컬 파일 시스템에 마운트합니다. 이는 NFS 공유를 뒷받침하는 파일 시스템이 될 것입니다.
$ truncate -s 512M 512BM-ext4.img
$ mkfs.ext4 512BM-ext4.img
$ sudo mkdir /mnt/ext4-file
$ sudo mount -o loop,noacl 512BM-ext4.img /mnt/ext4-file
그런 다음 NFSv4를 사용하여 네트워크를 통해 이 파일 시스템을 적절한 시스템으로 공유/내보냅니다. 이 예에서는 localhost를 사용하지만 로컬 네트워크의 모든 컴퓨터가 될 수 있습니다. /etc/exports다음과 같은 줄을 갖도록 편집하여 이 작업을 수행합니다 .
/mnt/ext4-file/ localhost(ro,fsid=123123)
그런 다음 컴퓨터에서 NFS 서버를 다시 시작하면 서비스 파일이 OS에 따라 다를 수 있습니다.
$ sudo systemctl restart nfs-server.service nfs-mountd.service
$ sudo exportfs -v
/mnt/ext4-file localhost(sync,wdelay,hide,no_subtree_check,fsid=123123,sec=sys,ro,secure,root_squash,no_all_squash)
root_squash및가 활성화되어 있는지 확인하세요 ro.
이제 원하는 클라이언트에 NFSv4 공유를 마운트할 수 있습니다.
$ sudo mount -t nfs -o ro localhost:/mnt/ext4-file /mnt/nfs-share/
$ findmnt /mnt/nfs-share
TARGET SOURCE FSTYPE OPTIONS
/mnt/nfs-share localhost:/mnt/ext4-file nfs4 rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255
그런 다음 이 공유 위에 overlayfs2를 마운트합니다.
$ mkdir -p /tmp/overlay/{work,upper}
$ sudo mkdir /mnt/overlay
$ sudo mount -t overlay overlay -o lowerdir=/mnt/nfs-share/,upperdir=/tmp/overlay/upper/,workdir=/tmp/overlay/work/ /mnt/overlay/
실험을 위해 파일 시스템에 사용자만 읽고 쓸 수 있고 그룹만 읽을 수 있는 폴더를 만듭니다. 내 사용자에게 속한 그룹을 선택했습니다.
$ sudo mkdir /mnt/ext4-file/rovanion
$ sudo chown rovanion:rovanion /mnt/ext4-file/rovanion
$ sudo chmod 2750 /mnt/ext4-file/rovanion
$ touch /mnt/ext4-file/rovanion/hi-from-ext4
$ ls -la /mnt/nfs-share/rovanion/
totalt 8,0K
drwxr-s--- 2 rovanion rovanion 4,0K sep 6 14:14 .
drwxr-xr-x 4 root root 4,0K sep 6 14:12 ..
-rw-rw-r-- 1 rovanion rovanion 0 sep 6 14:14 hi-from-ext4
$ touch /mnt/nfs-share/rovanion/hi-from-nfs
touch: cannot touch '/mnt/nfs-share/rovanion/hi-from-nfs': Read-only file system
의 내용을 나열할 수 있지만 /mnt/nfs-share/rovanionNFS 공유가 읽기 전용으로 마운트되어 있기 때문에 권한이 있어도 파일 시스템을 건드릴 수 없습니다. 모든 것이 예상대로입니다.
실패
그러나 여기서 문제가 발생합니다.
$ ls -la /mnt/overlay/rovanion/
ls: cannot open directory '/mnt/overlay/rovanion/': Permission denied
$ ls -l /mnt/overlay/
total 28K
drwx------ 2 root root 16K Sep 6 13:04 lost+found
drwxr-s--- 2 rovanion rovanion 4.0K Sep 6 14:14 rovanion
$ whoami
rovanion
$ groups
rovanion sudo
/mnt/overlay/rovanion권한 시스템에서 허용해야 하는 경우에도 목록에 대한 액세스가 거부됩니다 .
무슨 일이 일어나고 있는지에 대한 최선의 추측은 Overlayfs가 rootNFS의 루트 스쿼시에 의해 nobody폴더에 대한 액세스가 허용되지 않는 사람에게 매핑되는 기본 파일 시스템에 대한 모든 액세스를 수행한다는 것입니다. 왜냐하면 nobody그룹에 속하지 않고 rovanion다른 사용자는 허용되지 않기 때문입니다. 폴더를 나열하십시오.
질문
그렇다면 내 질문은 다음과 같습니다. 이 문제를 해결할 수 있습니까? NFS 내보내기/공유에서 root_squash를 비활성화하거나 o+rx폴더에 추가하지 않고 선택한 그룹만 액세스할 수 있는 Overlayfs를 통해 사용자 액세스를 허용합니다 .
답변1
다음 섹션의Overlayfs에 대한 Linux 커널 문서권한 모델을 설명합니다.
오버레이 파일 시스템의 권한 확인은 다음 원칙을 따릅니다.
1) permission check SHOULD return the same result before and after copy up 2) task creating the overlay mount MUST NOT gain additional privileges 3) non-mounting task MAY gain additional privileges through the overlay, compared to direct access on underlying lower or upper filesystems이는 각 액세스에 대해 두 번의 권한 확인을 수행하여 달성됩니다.
a) check if current task is allowed access based on local DAC (owner, group, mode and posix acl), as well as MAC checks b) check if mounting task would be allowed real operation on lower or upper layer based on underlying filesystem permissions, again including MAC checks확인(a)는 소유자, 그룹, 모드 및 posix acl이 복사되므로 일관성(1)을 보장합니다. 반면에 서버 강제 권한(예: NFS에서 사용)이 무시될 수 있습니다(3).
(b)를 확인하면 마운팅 작업에 없는 기본 레이어에 대한 권한을 얻는 작업이 없는지 확인합니다(2).이는 또한 일관성 규칙(1)이 유지되지 않는 설정을 생성하는 것이 가능하다는 것을 의미합니다. 그러나 일반적으로 탑재 작업에는 모든 작업을 수행할 수 있는 충분한 권한이 있습니다.
내 강조. 내가 읽은 것은 내가 그런 상황을 만들어냈다는 것입니다. 루트로 실행되는 탑재 작업에는 폴더를 나열할 권한이 없으므로 Overlayfs는 폴더에 대한 사용자 액세스를 허용하지 않습니다.
UID가 압축되지 않도록 루트가 아닌 파일에 액세스할 수 있는 사용자로 Overlayfs를 마운트한다면 디렉토리를 나열하고 그 안에 파일을 생성할 수 있을까요?
$ unshare --mount --map-root-user
# mount -t overlay overlay -o lowerdir=/mnt/nfs-share/,upperdir=/tmp/overlay/upper/,workdir=/tmp/overlay/work/ /mnt/overlay/
# ls -la /mnt/overlay/
totalt 28K
drwxrwxr-x 1 root root 4,0K sep 6 14:08 .
drwxr-xr-x 7 nobody nogroup 4,0K sep 6 14:09 ..
drwx------ 2 nobody nogroup 16K sep 6 13:04 lost+found
drwxr-s--- 2 root root 4,0K sep 6 14:14 rovanion
# touch /mnt/overlay/rovanion/hi-from-overlay
그리고 우리는 할 수 있습니다! 그리고 파일은 오버레이에만 존재합니다.
$ ls /mnt/ext4-file/rovanion/
hi-from-ext4
$ ls /tmp/overlay/upper/rovanion/
hi-from-overlay
이 솔루션에는 고유한 흥미로운 의미가 있습니다. 이제 우리는 100% 신뢰할 수 없는 컴퓨터에서 사용자 네임스페이스를 활성화해야 하며 UID가 0으로 보이지만 외부 세계의 일반 사용자 ID에 매핑되는 공간에 갑자기 존재하게 됩니다. 불행 unshare --mount하게도 없이는 --map-root-user불가능해 보입니다.