권한이없는 사용자가 파일 소유권을 변경할 수없는 이유는 무엇입니까?


15

chown (2)에서 :

권한있는 프로세스 (Linux : CAP_CHOWN 기능이있는 프로세스) 만 파일 소유자를 변경할 수 있습니다. 파일 소유자는 파일 그룹을 해당 소유자가 속한 그룹으로 변경할 수 있습니다. 권한있는 프로세스 (Linux : CAP_CHOWN 사용)는 그룹을 임의로 변경할 수 있습니다.

이 제한의 이유는 무엇입니까? 권한이없는 사용자가 소유 한 파일의 파일 소유권을 변경할 수없는 이유는 무엇입니까 (예 : / etc / shadow 없음)?

$ touch blah
$ chown root:root blah
chown: changing ownership of `blah': Operation not permitted

답변:


27

사용자가 파일을 "제공"하면 OS의 다양한 기능을 무시하게됩니다. 같은 :

Taking up another user's disk quota.
Impersonating another user (or even root) via setuid.
Having insufficient privileges to undo a mistaken chown.
Making it appear that someone else had created a given file.
Setting up cron jobs to run on other user's accounts.
And many more...

8

그것을 허용하지 않는 것은 리눅스 디자이너가 개인적으로 선택한 것입니다- 주어진 모든 의사 보안 이유 는 이것을 허용하는 유닉스 시스템이 있기 때문에 의문의 여지가 있습니다.

나는이 기능이 유닉스의 행동이 'System-V'(AT & T) 또는 버클리의 유닉스 (BSD)를 따랐는지 여부에 달려 있다고 생각합니다 ...

언급 된 다른 보안 문제는 다음과 같습니다.

  • setuid를 통해 다른 사용자 (또는 루트)로 가장

    문제 없음 : '소유자'를 변경하면 'setXid'비트 (U / G)가 지워집니다.

  • 잘못된 chown을 취소 할 수있는 권한이 없습니다

    실제로 '보안 위험'은 아니지만 사용자 변경을 허용하는 시스템에있을 수 있습니다. 소유 한 디렉토리에 있으면 다시 변경할 수 있습니다.

  • 다른 사람이 지정된 파일을 만든 것으로 보입니다.

    그것은 여전히 ​​당신이 쓸 수있는 디렉토리에있을 것입니다. 즉, 그룹 또는 전체에 쓰기 위해 열려 있지 않은 경우 (또는 특히 ACL을 사용할 수있는 경우) 홈 디렉토리로 이동할 수 없습니다.

  • 다른 사용자 계정에서 실행할 크론 작업 설정

    crondirs는 사용자가 소유하고 쓰기 가능할뿐 아니라 다른 사용자 도 읽을있도록 설정되어 있지 않기 때문에 다시 작동하지 않습니다 .

  • 누구나 소유권을 변경할 수 있으면 누구나 시스템의 모든 파일에 액세스 할 수있는 권한을 변경할 수 있습니다.

    아니요 : 사용자가 해당 파일이 포함 된 디렉토리를 '소유'한 경우에만 해당됩니다. 즉, 'passwd'라는 파일을 루트에 제공 할 수는 있지만 / etc /에 대한 쓰기 권한이 없으면 파일을 / etc /로 이동할 수 없습니다.

  • 할당량

    잠재적으로 유효한 점은 - 경우 당신이 할당량을 사용하지만, 그것은 것처럼 보인다는 합계-까지하면 홈 디렉토리하여 디스크 공간을 쉽게 감지; 유일한 문제는 여러 사용자가 쓸 수있는 디렉토리에있을 것입니다. 어떤 경우에는 해당 'dir'의 소유자가 갈 수 있습니다. 그것은 수도 이러한 시스템의 경우가 지원하는 경우에만 디렉토리에서이 작업을 수행 할 수있는 파일을 '포기'당신 '자신',하지만 그래서, 실제로이 할 수있는 시스템에 봤는데 이후 오랜 시간이되었습니다 정확한 제한이 기억 나지 않습니다.

나는 '파일을 제공하지 않음'을 허용하는 '무역'이 있다는 것을 기억하는 것 같습니다. 손...

위의 '답변'은 실제 답변이 아니기 때문에 답변으로 표시 해제해야한다고 말하고 싶습니다. IT는 디자인 결정에 가깝습니다. 트레이드 오프가 무엇인지 모르겠습니다.

유효하지 않은 보안 문제가있을 수 있지만 위의 문제는 유효하지 않습니다.

IMO는 "/ proc"에서 시스템 설정 가능한 '값'이어야하지만 일반적으로 대부분의 사람들은 그다지 신경 쓰지 않는다고 생각합니다.

이를 강력하게 필요로한다면 'chown'을 보안 강화 및 수정하여 수정 한 다음 w / setuid 'root'를 설정하여 이러한 정책을 구현할 수 있습니다.


할당량은 항상 위치가 아니라 파일 소유권을 기반으로합니다 . 그렇지 않으면 누군가가에 모든 것을 보관할 수 있습니다 . /tmp
user1686 년

+1, 당신은 옳아 보인다 :). OpenSolaris 시스템 (실제로 System V의 하위 시스템)에서는 mount옵션을 통해 이를 설정할 수 있습니다 (따라서이 설정은 시스템 설정 가능한 값 제안에 따라 시스템 전체가 아닌 단일 마운트 지점으로 제한 될 수 있음) : rstchown(기본값 )를 통해 파일 소유자 변경 사항을 루트 사용자로 제한하고 norstchown권한이없는 사용자가 자신의 파일 소유자를 변경할 수 있도록합니다 (다시 변경할 수 없음).
WhiteWinterWolf

6

누구나 소유권을 변경할 수 있다면 누구나 권한을 변경하여 시스템의 모든 파일에 액세스 할 수 있습니다. 이것은 맬웨어 관점 (sudo 필요 없음)뿐만 아니라 sysadmin의 관점에서도 좋지 않습니다. 사용자 중 하나라도 파일을 변경할 수 있으면 파일 권한이 쓸모가 없습니다.


2
권리. 나는 파일이 아닌 사용자 소유의 파일을 언급하고 있음을 분명히하기 위해 질문을 수정했습니다.
Alexandru

1
@Alexandru : 악의적 인 사용자 myTrojan.sh가 root가 소유하고 SUID 플래그를 갖도록 변경하는 것을 생각해보십시오 .
Benjamin Bannier

@honk : 이제 말이됩니다.
Alexandru

5

따라서 사용자는 파일 시스템 할당량을 회피 할 수 있습니다. 할당량이 100MB이고 할당량이 100MB 인 경우 100MB, chmod a + r, chown을 업로드 한 다음 다른 100MB를 업로드 할 수 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.