톰캣을 새로 깔았는데 권한 점검에 또 걸릴 때 (tar가 남긴 디렉터리 모드와 umask)

권한을 분명히 조치했는데 다음 점검에서 또 지적받는 경우가 있습니다. 파일과 디렉터리의 권한이 정해지는 방식이 다르기 때문인데, 왜 그런지와 근본 해결을 알아보는 글입니다.

1. 증상 - 분명히 바꿨는데 또 걸린다

취약점 점검에서 "설치 경로에 다른 사용자 권한이 열려 있다"는 지적을 받으면 보통 conf 아래를 손보고 넘어가는데, 다음 점검에서 같은 항목이 또 올라옵니다.

이번에는 logs, temp, work, webapps 가 지적되는 식이라, 하나 막으면 다른 게 나오는 두더지잡기처럼 느껴집니다.

여기서 놓치기 쉬운 게, 압축을 풀 때부터 파일과 디렉터리의 권한이 서로 다르게 정해졌다는 점입니다. 조치를 덜 한 게 아니라 애초에 출발선이 달랐던 것입니다.

2. 원인 - umask는 디렉터리에 안 먹는다

톰캣을 설치할 때 보통 압축을 풀어서 씁니다. 그런데 같은 명령으로 풀었는데도 결과가 이렇게 갈립니다.

파일은 umask가 적용돼 다른 사용자 권한이 떨어져 있는데, 디렉터리는 배포본에 기록된 모드 그대로 남습니다.

이유는 tar가 디렉터리를 만드는 방식에 있습니다. 압축을 푸는 동안에는 그 안에 파일을 써 넣어야 하니 일단 넉넉한 권한으로 디렉터리를 만들어 두고, 추출이 다 끝난 뒤에 아카이브에 기록된 모드를 chmod로 되돌려 놓습니다.

여기가 핵심인데, umask는 파일이나 디렉터리를 새로 만들 때만 적용되고 chmod에는 적용되지 않습니다. 그래서 파일은 umask를 타고, 디렉터리는 umask를 우회해 배포본 모드가 그대로 살아남습니다.

3. chmod만으로는 왜 부족한가

지적받은 디렉터리를 하나씩 바꾸면 그 순간에는 통과하지만, 이건 조치한 시점의 것만 바뀐 상태입니다.

톰캣은 기동할 때 work 와 temp 를 다시 만드는데, 그때는 tar가 아니라 자바 프로세스가 직접 만들기 때문에 그 프로세스의 umask를 따릅니다. 프로세스 umask가 느슨하면 재기동 한 번에 원래대로 돌아가고, 그래서 다음 점검에 또 걸립니다.

즉 chmod는 이미 있는 것을 치우는 일이고, 앞으로 생길 것까지 막으려면 umask 쪽을 잡아야 합니다. 두 가지를 다 해야 끝납니다.

4. umask는 setenv.sh에 넣는다

톰캣 기동 스크립트는 여러 갈래로 불립니다. 직접 startup.sh 를 쓰기도 하고, 서비스로 등록해 돌리기도 하고, 재기동 스크립트를 따로 만들어 쓰기도 합니다.

그런데 catalina.sh 는 어느 경로로 들어오든 setenv.sh 를 먼저 읽습니다. 그래서 여기에 umask를 넣어 두면 기동 방식과 무관하게 항상 적용됩니다.

이미 만들어진 것들은 find 로 정리하는데, 디렉터리만 골라서 바꾸는 편이 안전합니다. chmod -R 로 한 번에 밀면 실행 권한이 필요한 스크립트까지 건드릴 수 있어서, 대상을 좁혀 두는 쪽이 사고가 적습니다.

5. 여기서 걸리는 함정 두 가지

심볼릭 링크는 권한을 못 바꿉니다. 링크 자체는 항상 모든 권한이 열린 것처럼 보이고, chmod 를 걸면 링크가 아니라 가리키는 대상이 바뀝니다. 점검 목록에 링크가 올라왔다면 조치가 아니라 소명할 항목이라, 미리 알고 있어야 대응이 됩니다.

로그 수집이 조용히 끊길 수 있습니다. 다른 사용자 권한을 떨어뜨리면 그 순간부터 다른 계정으로 도는 수집 에이전트가 로그를 못 읽습니다. 에러가 나는 게 아니라 그냥 안 들어오기 때문에, 한참 뒤에야 알아차리게 됩니다.

그래서 권한을 조이기 전에 누가 이 디렉터리를 읽고 있는지부터 확인하고, 필요하면 수집 계정을 같은 그룹에 넣어 두는 편이 낫습니다.

6. 정리

- 압축을 풀면 파일은 umask를 타고 디렉터리는 안 탄다

- 이유는 tar가 디렉터리 권한을 chmod 로 나중에 되돌리기 때문이다

- chmod 는 이미 있는 것만 고치고, work/temp 는 재기동 때 다시 생긴다

- 그래서 근본은 setenv.sh 의 umask, 정리는 디렉터리만 골라서

- 심볼릭 링크는 조치 대상이 아니라 소명 대상이고, 로그 수집 계정은 미리 확인한다

같은 지적을 두 번 받으면 조치를 대충 했나 싶어지지만, 이 경우엔 파일과 디렉터리가 서로 다른 규칙으로 만들어졌을 뿐입니다. 규칙이 다르다는 것만 알면 어디를 막아야 할지도 같이 보입니다.

함께 보면 좋은 글:
- 톰캣(Tomcat) allowLinking 취약점 조치하면서 기능은 살리기 (심볼릭 링크 대신 전용 Context 매핑) - 같은 톰캣 취약점 조치 편
- 톰캣(Tomcat) 6에서 9로 올릴 때 만나는 함정 5가지 (기동 실패, 한글 전멸, 400 에러) - 같은 톰캣 이관 편

여기까지 압축 해제 시 디렉터리 권한이 umask를 타지 않는 이유에 대해서 작성해봤습니다. 여기까지 읽어주셔서 감사합니다!