chgrp가 "setuid 비트"를 지우는 것을 방지하는 방법은 무엇입니까?

Question 1

chgrp -R nobody /whateversetuid 비트를 유지하면서 이를 달성 하려면 다음 두 find명령을 사용할 수 있습니다.

find /whatever ! -type l -perm -04000 -exec chgrp nobody {} + \
                                      -exec chmod u+s {} +
find /whatever ! -type l ! -perm -04000 -exec chgrp nobody {} +

이 find ... -perm 04000옵션은 setuid 비트가 설정된 파일을 선택합니다. 그런 다음 첫 번째 명령은 a를 적용한 chgrp다음 a를 적용하여 chmod취소된 setuid 비트를 복원합니다. 두 번째는 chgrpsetuid 비트가 없는 모든 파일에 적용됩니다.

chgrp어떤 상황에서도 호출 하거나 심볼릭 링크를 사용 하고 싶지 않습니다. chmod이는 대상에 영향을 미치므로 ! -type l.

Answer

chgrp -R nobody /whateversetuid 비트를 유지하면서 이를 달성 하려면 다음 두 find명령을 사용할 수 있습니다.

find /whatever ! -type l -perm -04000 -exec chgrp nobody {} + \
                                      -exec chmod u+s {} +
find /whatever ! -type l ! -perm -04000 -exec chgrp nobody {} +

이 find ... -perm 04000옵션은 setuid 비트가 설정된 파일을 선택합니다. 그런 다음 첫 번째 명령은 a를 적용한 chgrp다음 a를 적용하여 chmod취소된 setuid 비트를 복원합니다. 두 번째는 chgrpsetuid 비트가 없는 모든 파일에 적용됩니다.

chgrp어떤 상황에서도 호출 하거나 심볼릭 링크를 사용 하고 싶지 않습니다. chmod이는 대상에 영향을 미치므로 ! -type l.

Question 2

에서 SUID 및 SGID 비트를 지우는 chgrp(또는 ) 것이 완벽합니다. chown이는 보안 문제를 방지하기 위한 보안 조치입니다. 실행 파일에 있는 SGID의 경우유효한 그룹 소유자 그룹으로 이 프로그램을 실행하세요..

그룹 소유자를 변경하면 보안 및 액세스 제어 측면에서 완전히 달라집니다. 즉, uvw이제 프로그램은 유효 그룹 대신 유효 그룹으로 실행됩니다 xyz.

따라서 소유권이 변경되면 SUID 또는 SGID 비트를 명시적으로 복원해야 합니다.

부록: chgrp(또는 chown)가 SGID(또는 SUID)만 지워야 한다는 주장

chowning 또는 ing을 사용하면 chgrp실행 파일의 보안 설정을 변경할 수 있으며 이는 모든 권한 에스컬레이션 속성을 지우는 데 충분합니다. 유닉스의 힘은 개념의 단순성에서 나오는데, 유닉스의 보안은 이미 상당히 까다롭다. 이러한 이유로 소유권 변경 시 SUID 및 SGID를 제거하는 것은 단지 안전망일 뿐입니다. 결국 Unix/Linux 역사상 잘못된 SUID 또는 SGID 설정으로 인해 취약점이 꽤 많이 있었습니다.

그러므로 유닉스가 지금처럼 행동하는 더 깊은 이유는 없습니다. 그것은 단지 보수적인 디자인 결정일 뿐입니다.

Answer

에서 SUID 및 SGID 비트를 지우는 chgrp(또는 ) 것이 완벽합니다. chown이는 보안 문제를 방지하기 위한 보안 조치입니다. 실행 파일에 있는 SGID의 경우유효한 그룹 소유자 그룹으로 이 프로그램을 실행하세요..

그룹 소유자를 변경하면 보안 및 액세스 제어 측면에서 완전히 달라집니다. 즉, uvw이제 프로그램은 유효 그룹 대신 유효 그룹으로 실행됩니다 xyz.

따라서 소유권이 변경되면 SUID 또는 SGID 비트를 명시적으로 복원해야 합니다.

부록: chgrp(또는 chown)가 SGID(또는 SUID)만 지워야 한다는 주장

chowning 또는 ing을 사용하면 chgrp실행 파일의 보안 설정을 변경할 수 있으며 이는 모든 권한 에스컬레이션 속성을 지우는 데 충분합니다. 유닉스의 힘은 개념의 단순성에서 나오는데, 유닉스의 보안은 이미 상당히 까다롭다. 이러한 이유로 소유권 변경 시 SUID 및 SGID를 제거하는 것은 단지 안전망일 뿐입니다. 결국 Unix/Linux 역사상 잘못된 SUID 또는 SGID 설정으로 인해 취약점이 꽤 많이 있었습니다.

그러므로 유닉스가 지금처럼 행동하는 더 깊은 이유는 없습니다. 그것은 단지 보수적인 디자인 결정일 뿐입니다.

Question 3

setuid비디렉토리 비트 지우기(적어도 Linux에서는)는 커널 자체가 아닌 시스템 호출을 완료할 때 커널에 의해 수행 setgid됩니다 . 따라서 유일한 방법은 나중에 회복하는 것입니다.chown()chgrpchgrp

또한 보안 기능도 삭제됩니다.

따라서 GNU Linux에서는:

chown_preserve_sec() (
  newowner=${1?}; shift
  for file do
    perms=$(stat -Lc %a -- "$file") || continue
    cap=$(getfattr -m '^security\.capability$' --dump -- "$file") || continue
    chown -- "$newowner" "$file" || continue
    [ -z "$cap" ] || printf '%s\n' "$cap" | setfattr --restore=-
    chmod -- "$perms" "$file"
  done
)

그리고 다음을 실행합니다(예 root: ):

chown_preseve_sec :newgroup file1 file2...

권한을 유지하면서 그룹을 변경하세요.

재귀적으로 다음을 수행할 수 있습니다.

# save permissions (and ACLs). Remove the "# owner" and "# group" lines
# to prevent them being restored!
perms=$(getfacl -RPn . | grep -vE '^# (owner|group): ')
# save capabilities
cap=$(getfattr -Rhm '^security\.capability$' --dump .)

chgrp -RP nobody .

# restore permissions, ACLs and capabilities
printf '%s\n' "$perms" | setfacl --restore=-
[ -z  "$cap" ] || printf '%s\n' "$cap" | setfattr -h --restore=-

(이것은 동시에 파일을 손상시키는 다른 것이 없다고 가정합니다).

Answer