[시스템][보안] su 사용자 제한 (퍼미션)
이건 요 아래의 gcc 권한 처리 하는것과 같죠?
group 권한을 이용하는 거죠..
su 명령어를 실행할 수 있는 아이디를 uheung 이라고 합니다.
# vi /etc/group
sugroup:x:22:uheung
를 추가하고
# chgrp sugroup /bin/su
# chmod 4710 /bin/su
# ls -l /bin/su
-rws–x— 1 root sugroup 14188 3월 7 2000 /bin/su
이제 su 명령어는 uheung 아이디만 사용가능 합니다.
** 주의 이때 chmod 4710 으로 꼭 주셔야 합니다.
suid 가 있어야지 되는 프로그램입니다. 안그러면 console 에 가야 됩니다~
기롬~
위 자료 잘보았습니다.
테스트중 궁금한점이 있어서 글을 쓰게되었습니다.테스트는 아래와 같이 2가지 방법으로 테스트를 해보았습니다.
테스트 방법1
1. usermod -G wheel admin
2. chmod 4710 /bin/su
3. chown root.wheel /bin/su
테스트방법2
1. usermod -G wheel admin
2. chown root.wheel /bin/su
3. chmod 4710 /bin/su
위 2가지 테스트 방법에서 2번째 테스트는 admin에 대해서만 적용이 되어 정상적으로 되었습니다. 하지만 1번째 테스트에서는 admin 계정으로 su – 사용시
-bash: /bin/su: Permission denied 라고 메세지는 나오지 않으나 패스워드를 정확히 입력해도 root계정으로 접속을 할수 없었습니다.
저의 생각으로 두가지 테스트방법이 소유권과 허가권의 설정 순서만 틀릴뿐 같은 설정이라고 보는데 결과가 틀린것이 궁금해서 이렇게 질문을 드립니다.
setuid 퍼미션 설정이 되어 있는 파일의 경우, 소유권이 바뀌면 “s”속성이 사라집니다.
그냥 쉽게 생각하면 setuid, setgid 란 x(실행) 권한이 있는 일반 사용자 계정이 해당 파일을 실행할때 소유자 권한으로 실행할 수 있게 허용하는 것입니다.
퍼미션 보다는 소유자 정보가 더 우선이다 볼수 있죠.
root 소유의 파일에 setuid 퍼미션 권한을 주었는데, 소유권이 변경되는 chown 명령 수행된다면..
setuid가 유지되는 것이 맞을까요? 중지되는 것이 맞을까요? 중지되는 것이 안전하겠죠!!
가장 중요한것은 “-bash: /bin/su: Permission denied ” 메세지가 떨어졌을때 /bin/su 의 퍼미션을
확인해 보는 것이 중요합니다. 그럼..4710이 아닌, 710으로 변경되어 있을 것입니다. 시스템을 관리하기 위해서는 시스템에서 나타나는 형상만 보고 판단할것이 아니라, 이상 현상의 시작이 되는 원인을 찾고, 확인을 해야합니다.
su 명령은 setuid 가 반드시 허용되어 있어야 하는 명령입니다. 일반 사용자가 다른 사용자의 권한
을 얻는것이기 때문에 원칙적으로는 root 만이 할수 있는 영역입니다. 그렇기에 허용된 사용자에게
해당 명령에 한해서 root 의 권한을 잠시 위임하는 거라 생각하시면 됩니다.