저자는 setuid/setgid 보안적인 코드에 대해 csh, sh 와 bash 와 같은 표준 커맨드 쉘 스크립팅 언어를 사용하지 말라고 추천한다. 리눅스와 같은 몇몇 시스템들은 이들을 완전히 금지하기 때문에 불필요한 이식성 문제를 만들 수 있다. 어떤 오래된 시스템에서 이들은 3.1.3절 에서 논의된 바와 같이 경쟁 상태때문에 기본적으로 비보안적이며 다른 시스템에 대해서도 이들은 실제로 좋은 개념이 아니다. 표준 커맨드 쉘은 아직도 명백하지 않은 입력에 의해 영향을 받는 것으로 유명한데 이는 일반적으로 커맨드 쉘이 과감한 공격자에 대해 보호하는 것이 아니라 대화식 사용자들을 위해 자동적으로 작업을 하려고 설계되었기 때문이다. 예를 들어 숨겨진 환경 변수 (예, ENV 또는 BASH_ENV 변수) 는 스크립트가 실행될 수 있기 전이라도 임의의 사용자 정의 코드를 어떻게 연산 또는 더 나아가서는 실행시키는지에 영향을 미칠 수 있다. 실행가능 파일의 이름 또는 디렉토리 내용같은 것들도 영향을 끼칠 수 있는데 예를 들어 많은 Bourne 쉘 구현에서 다음은 루트 권한을 줄 수 있다 (이 악용 설명에 대해 NCSA 에 감사한다).
% ln -s /usr/bin/setuid-shell /tmp/-x % cd /tmp % -x |
아직도 쉘 스크립팅 언어의 사용을 주장한다면 적어도 스크립트를 이동 또는 변경될 수 없는 디렉토리내에 두어라. 스크립트의 맨 앞에 PATH 와 IFS 를 알려진 값들로 설정해라.
비슷한 맥락으로 저자는 보안적인 정책을 구현하는 ``제한적인 쉘" 을 신뢰하지 않아야 한다고 충고한다. 제한적인 쉘은 의도적으로 사용자로 하여금 많은 작업을 수행하지 못하게 하는 쉘로 그 목적은 사용자에게 단지 아주 소수의 프로그램들만을 실행시킬 수 있도록 하는 것이다. 제한적인 쉘은 철처한 방어 (defense-in-depth) 조치로 유용할 수 있지만 정확하게 설정하는 것이 어렵다고 알려져 있으며 설정되더라도 대개 파괴될 수 있다. 예를 들어 몇몇 제한적인 쉘은 제한되지 않은 모드에서 어떤 파일 (예, ``.profile) 을 실행시킴으로써 시작될 수 있다. - 사용자가 이 파일을 변경시킬 수 있다면 쉘은 변경된 코드를 실행시키는 것이다. 제한적인 쉘은 단지 약간의 프로그랭만을 실행시킬 수 있도록 설정되어야 하지만 그러한 프로그램중 어떤 프로그램이 사용자들로 하여금 더욱 많은 프로그램을 실행시키도록 하는 ``쉘 이스케이프" 를 갖고 있다면 공격자가 이러한 쉘 이스케이프를 사용해 제한적인 쉘을 이스케이프할 수 있다. 물론 제한적인 쉘의 PATH 를 설정하지 않아 어떤 프로그램도 실행될 수 없도록 설정한다 하더라도 공격자는 텍스트 편집기, 메일러 등 많은 프로그램의 쉘 이스케이프를 사용할 수 있다. 문제는 쉘의 목적이 다른 프로그램을 실행시키는 것이지만 그러한 다른 프로그램이 의도되지 않은 연산을 허용할 수도 있다는 것이다. -- 쉘은 이러한 연산을 못하도록 개입하지 않는다.