얼마전 securityfocus에서 "/proc filesystem allows bypassing directory permissions on Linux" 라는 제목으로 토론이 있었습니다.
스레드는 http://www.securityfocus.com/archive/1/507386/30/120/threaded 여기서부터 시작하구요.
Pavel이란 사람이 lkml에서는 해당 내용에 대해 보안 취약성으로 보지 않을거라고 하며 securityfocus에 올렸고
이에 대한 내용은 디렉토리와 파일 퍼미션간의 권한 체계 디자인과 관련되어 있습니다.
누구는 security hole로 보고, 누구는 그렇지 않다는 식으로 이야기가 오가지만,
솔직히 제 생각에도 보안 취약성으로 보이지는 않습니다.
다음은 해당 문제점(?) 입니다.
< root terminal >
-----------------------------------------------
[root@hkpco hk]# cat > hkpco.kr
chanam park
[root@hkpco hk]# chmod 666 hkpco.kr
// 해당 작업이 없다면,
// 이후 일반 사용자는 읽기만 가능하게 됨.
[root@hkpco hk]# chmod 700 .
-----------------------------------------------
< user terminal >
-----------------------------------------------
[hkpco@hkpco user]$ ln /tmp/hk/hkpco.kr .
[hkpco@hkpco user]$ ls
hkpco.kr
[hkpco@hkpco user]$ cat hkpco.kr
chanam park
-----------------------------------------------
< root terminal >
-----------------------------------------------
[root@hkpco hk]# chmod 700 .
[root@hkpco hk]# cat hkpco.kr
chanam park
-----------------------------------------------
< user terminal >
-----------------------------------------------
[hkpco@hkpco user]$ cat /tmp/hk/hkpco.kr
cat: /tmp/hk/hkpco.kr: Permission denied
[hkpco@hkpco user]$ cd /tmp/hk
-bash: cd: /tmp/hk: Permission denied
[hkpco@hkpco user]$ cat hkpco.kr
chanam park
[hkpco@hkpco user]$ cat > hkpco.kr
hkpco
[hkpco@hkpco user]$ cat hkpco.kr
hkpco
-----------------------------------------------
< root terminal >
-----------------------------------------------
[root@hkpco hk]# cat hkpco.kr
hkpco
-----------------------------------------------
요약하면, 루트(혹은 다른 유저)가 사용중인 파일이 존재하는 디렉토리의 권한을 700으로 막아두어도,
그 이전에(해당 디렉토리 권한이 잠시 열려있었을 때), hard link를 통하여 파일을 링크 시켜두게 되면,
이후 해당 디렉토리 권한이 700으로 막혀있어도, 디렉토리나 파일에 직접적으로 접근할 수는 없지만,
미리 걸어둔 hard link로 권한이 막혀있는 디렉토리에 존재하는 파일에 접근이 가능하다는 것입니다.
이러한 상황이 가능한 이유는, 이미 오픈되었거나 hard link를 걸어둔 파일은 접근 시 inode를
이용해서 접근 가능 여부를 체크하는데, 이 때 해당 디렉토리의 권한 체크는 생략되기 때문입니다.
예를들면, open() 시스템 콜 호출시에는 물론 권한 검사를 하겠지만, 이후 read(), write() 시스템콜 등이
호출될 때 까지 매번 검사를 하지는 않습니다. 만약 그렇게 되면 퍼포먼스가 떨어지기도 할테구요.
그리고 inode에 해당 파일의 정보가 아닌 상위 디렉토리틀의 권한 정보까지 모두 포함되지는 않죠..
누구는 권한 체계상의 문제점이 아닌가 라고 말하기도 하는데, 개인적으로 그렇지 않다고 보여집니다.
일단 디렉토리의 권한은 그 하위에 존재하는 전체 파일의 권한까지 담당하는것이 아니라,
해당 디렉토리의 접근 제한 등, 단지 디렉토리에 대한 퍼미션을 위한것입니다.
디렉토리는 디렉토리대로, 파일은 파일대로 각각의 역할을 충실히 담당하는것이죠.
파일 및 디렉토리 상호간의 협력을 통해서 이러한 논점을 해결할 수 있을지는 모르겠지만,
어느 하나가 그러한 권한 체계를 무시하고 제한한다면 엄연한 월권이 아닐까 생각되구요.
아무튼, 이를 통해 발생할 수 있는 문제점은 별로 크지 않을것 같지만 그래도 한 가지 가정해보면,
퍼미션이 조정되는 갭 타임에 hard link를 통하여 미리 링크를 걸어두었다면, 이후 디렉토리 퍼미션이
변경되어도 해당 파일의 변경사항을 주기적으로 모니터링 및 퍼미션에따라 직접 수정도 가능할 것으로 보입니다.
물론 이러한 방법을 이용하지 않고, 그냥 갭 타임에 주기적으로 읽기를 시도하면 몇 번 성공할지는 모르겠지만,
그건 그 순간이고, 이후에 디렉토리 권한이 막힌다면 더이상의 access는 힘들겠죠.
스레드는 http://www.securityfocus.com/archive/1/507386/30/120/threaded 여기서부터 시작하구요.
Pavel이란 사람이 lkml에서는 해당 내용에 대해 보안 취약성으로 보지 않을거라고 하며 securityfocus에 올렸고
이에 대한 내용은 디렉토리와 파일 퍼미션간의 권한 체계 디자인과 관련되어 있습니다.
누구는 security hole로 보고, 누구는 그렇지 않다는 식으로 이야기가 오가지만,
솔직히 제 생각에도 보안 취약성으로 보이지는 않습니다.
다음은 해당 문제점(?) 입니다.
< root terminal >
-----------------------------------------------
[root@hkpco hk]# cat > hkpco.kr
chanam park
[root@hkpco hk]# chmod 666 hkpco.kr
// 해당 작업이 없다면,
// 이후 일반 사용자는 읽기만 가능하게 됨.
[root@hkpco hk]# chmod 700 .
-----------------------------------------------
< user terminal >
-----------------------------------------------
[hkpco@hkpco user]$ ln /tmp/hk/hkpco.kr .
[hkpco@hkpco user]$ ls
hkpco.kr
[hkpco@hkpco user]$ cat hkpco.kr
chanam park
-----------------------------------------------
< root terminal >
-----------------------------------------------
[root@hkpco hk]# chmod 700 .
[root@hkpco hk]# cat hkpco.kr
chanam park
-----------------------------------------------
< user terminal >
-----------------------------------------------
[hkpco@hkpco user]$ cat /tmp/hk/hkpco.kr
cat: /tmp/hk/hkpco.kr: Permission denied
[hkpco@hkpco user]$ cd /tmp/hk
-bash: cd: /tmp/hk: Permission denied
[hkpco@hkpco user]$ cat hkpco.kr
chanam park
[hkpco@hkpco user]$ cat > hkpco.kr
hkpco
[hkpco@hkpco user]$ cat hkpco.kr
hkpco
-----------------------------------------------
< root terminal >
-----------------------------------------------
[root@hkpco hk]# cat hkpco.kr
hkpco
-----------------------------------------------
요약하면, 루트(혹은 다른 유저)가 사용중인 파일이 존재하는 디렉토리의 권한을 700으로 막아두어도,
그 이전에(해당 디렉토리 권한이 잠시 열려있었을 때), hard link를 통하여 파일을 링크 시켜두게 되면,
이후 해당 디렉토리 권한이 700으로 막혀있어도, 디렉토리나 파일에 직접적으로 접근할 수는 없지만,
미리 걸어둔 hard link로 권한이 막혀있는 디렉토리에 존재하는 파일에 접근이 가능하다는 것입니다.
이러한 상황이 가능한 이유는, 이미 오픈되었거나 hard link를 걸어둔 파일은 접근 시 inode를
이용해서 접근 가능 여부를 체크하는데, 이 때 해당 디렉토리의 권한 체크는 생략되기 때문입니다.
예를들면, open() 시스템 콜 호출시에는 물론 권한 검사를 하겠지만, 이후 read(), write() 시스템콜 등이
호출될 때 까지 매번 검사를 하지는 않습니다. 만약 그렇게 되면 퍼포먼스가 떨어지기도 할테구요.
그리고 inode에 해당 파일의 정보가 아닌 상위 디렉토리틀의 권한 정보까지 모두 포함되지는 않죠..
누구는 권한 체계상의 문제점이 아닌가 라고 말하기도 하는데, 개인적으로 그렇지 않다고 보여집니다.
일단 디렉토리의 권한은 그 하위에 존재하는 전체 파일의 권한까지 담당하는것이 아니라,
해당 디렉토리의 접근 제한 등, 단지 디렉토리에 대한 퍼미션을 위한것입니다.
디렉토리는 디렉토리대로, 파일은 파일대로 각각의 역할을 충실히 담당하는것이죠.
파일 및 디렉토리 상호간의 협력을 통해서 이러한 논점을 해결할 수 있을지는 모르겠지만,
어느 하나가 그러한 권한 체계를 무시하고 제한한다면 엄연한 월권이 아닐까 생각되구요.
아무튼, 이를 통해 발생할 수 있는 문제점은 별로 크지 않을것 같지만 그래도 한 가지 가정해보면,
퍼미션이 조정되는 갭 타임에 hard link를 통하여 미리 링크를 걸어두었다면, 이후 디렉토리 퍼미션이
변경되어도 해당 파일의 변경사항을 주기적으로 모니터링 및 퍼미션에따라 직접 수정도 가능할 것으로 보입니다.
물론 이러한 방법을 이용하지 않고, 그냥 갭 타임에 주기적으로 읽기를 시도하면 몇 번 성공할지는 모르겠지만,
그건 그 순간이고, 이후에 디렉토리 권한이 막힌다면 더이상의 access는 힘들겠죠.
덧글