저는 Ubuntu Linux 시스템을 실행하고 있습니다. 다른 공급업체(예: Chrome 및 Firefox)에서 작성한 애플리케이션을 실행하면 해당 애플리케이션이 모두 내 UID를 사용하여 실행되고 있음을 알 수 있습니다. 그러나 그렇다면 파일 시스템에 생성된 모든 파일도 동일한 uid를 갖게 됩니다. 그렇다면 Linux에서는 서로 신뢰하지 않는 두 애플리케이션이 어떻게 서로 파일의 보안을 보장합니까?
- ACL 정책을 사용하는 애플리케이션 A는 여전히 애플리케이션 B가 (사용자, 그룹, 기타)의 사용자 부분을 통해 A의 파일을 읽도록 허용할 수 있습니다.
- 애플리케이션은 서로의 데이터를 보호하기 위해 암호화를 사용해야 합니까?
답변1
문자 그대로의 대답은 귀하의 계정에서 실행되는 신뢰할 수 없는 응용 프로그램이 없다는 것입니다. 신뢰할 수 없는 애플리케이션을 실행하려면 다른 계정이나 가상 머신에서 실행하세요.
Unix, Windows 등의 일반적인 데스크톱 운영 체제와 Android, iOS 등의 일반적인 모바일 운영 체제에는 서로 다른 보안 모델이 있습니다. 유닉스는 사용자가 서로를 신뢰하지 않는 다중 사용자 운영 체제입니다.적용분야신뢰할 수 있는 것으로 간주됨: 사용자의 모든 애플리케이션이 동일한 보안 컨텍스트 내에서 실행됩니다.제공하다반면에 신뢰도가 낮습니다. 일반적으로 보안 위반이 발생할 경우 영향을 줄이기 위해 전용 계정에서 실행됩니다.
Unix 보안 모델은 다음과 같은 두 가지 주요 이유로 이러한 방식으로 작동합니다.
- 부정적인 이유는 역사 때문입니다. Unix가 설계되었을 때 응용 프로그램은 소규모 프로그래머 그룹에서 나왔고 공급업체의 평판에 의해 뒷받침되거나 소스 코드로 제공되었거나 둘 다였습니다. 애플리케이션의 백도어에 대해 걱정하는 사람은 거의 없습니다. 또한 네트워크를 통해 통신하는 애플리케이션이 거의 없기 때문에 취약점을 유발하고 악용할 기회가 상대적으로 적습니다. 따라서 애플리케이션을 서로 격리하려는 강력한 인센티브가 없습니다.
- 긍정적인 이유 중 하나는 기능성입니다. 앱을 분리하면 많은 일이 불가능해집니다. 각 애플리케이션이 자체 데이터 영역을 가지면 애플리케이션 간에 데이터를 공유하기가 어려워집니다. 일반적인 Unix 시스템에서는 여러 응용 프로그램이 동일한 데이터를 처리하는 것이 일반적입니다. Unix는 "응용 프로그램"과 "운영 체제"를 명확하게 구분하지 않기 때문에 특히 그렇습니다. 웹 브라우저는 응용 프로그램입니다. 브라우저는 자체 디렉토리로 제한되어 있기 때문에 사용자가 선택한 디렉토리에 파일을 다운로드할 수 없으며 이는 성가신 일입니다. 로그인 시 메뉴와 아이콘을 표시하는 프로그램도 동일한 기반을 가진 애플리케이션입니다. 정의상 모든 파일에 액세스해야 하는 파일 관리자의 경우에도 마찬가지입니다. 어디에서나 스크립트를 실행하는 쉘 및 기타 인터프리터에도 마찬가지입니다. 워드 프로세서에서 문서를 인쇄할 때 문서를 인쇄 가능한 형식으로 변환하는 응용 프로그램과 데이터를 프린터로 보내는 다른 응용 프로그램이 필요할 수 있습니다.
오늘날에는 40년 전보다 더 많은 애플리케이션 작성자가 있지만 애플리케이션은 여전히 평판 지표가 있는 신뢰할 수 있는 채널을 통해 배포됩니다. (이는 Windows보다 Linux에서 훨씬 더 사실이며, 이는 Windows에서 바이러스가 더 흔한 이유 중 하나입니다.) 백도어가 있는 것으로 발견된 응용 프로그램은 Linux 소프트웨어 저장소에서 즉시 제거됩니다.
모바일 운영 체제는 다양한 위협을 염두에 두고 설계되었습니다. 단일 사용자 시스템용으로 설계되었지만 해당 응용 프로그램은 완전히 신뢰할 수 없는 소스에서 제공됩니다.
응용 프로그램 격리가 데스크톱 Unix 시스템으로 확산되기 시작했습니다. 일부 배포판은 보안 프레임워크에서 특정 프로그램을 실행합니다.갑옷을 적용또는SELinux이로 인해 애플리케이션이 수행할 수 있는 작업이 제한됩니다. 이러한 보안 제한으로 인해 제한된 응용 프로그램이 특정 디렉터리에서 파일을 열지 못하게 하는 등 의도한 목적을 방해하는 경우가 있습니다.
암호화는 전혀 쓸모가 없습니다. 암호화는 데이터만 보호합니다.도중에(웹을 통해) 또는쉬고 있는(디스크에 저장됨) 라이브 시스템의 데이터를 보호하지 않습니다. 하위 시스템 A가 해당 데이터를 해독하면 운영 체제는 하위 시스템 B가 해독된 데이터에 액세스하는 것을 차단합니다. 암호화된 저장소가 아닙니다. 운영 체제는 데이터를 암호화할 수 있지만 저장 매체를 도난당한 경우에만 데이터를 보호할 수 있습니다.
신뢰할 수 없는 코드를 실행하려는 경우 가장 좋은 방법은 해당 코드를 가상 머신에서 실행하는 것입니다. 가상 머신이 애플리케이션에 필요한 파일에만 액세스하도록 허용합니다(예: 홈 디렉터리를 공유하지 않음).
당신은 또한 볼 수 있습니다모바일 앱에는 세분화된 권한이 있지만 데스크톱 앱에는 없는 이유는 무엇입니까?그리고모바일 장치용 앱이 데스크톱 장치용 앱보다 더 제한적인 이유는 무엇입니까?
답변2
나는 Giles의 답변을 좋아하지만 고려해야 할 또 다른 측면이 있습니다.
유닉스의 원칙 중 하나는 모든 프로그램이 "한 가지 일을 잘해야 한다"는 것이다.
프로그램은 사용자가 프로그램 실행 결과를 예측할 수 없을 정도로 너무 크고 복잡해져서는 안 됩니다. 올바른 UNIX 프로그램이 파일에 닿았다면 이는 다음과 같습니다.말하다파일에 닿습니다. 프로그램이 사용자가 지시하는 것 이상도 이하도 수행해서는 안 된다는 생각은 사용자가 의도하지 않은 방식으로 프로그램이 상호 작용하는 것을 방지합니다.
이 원칙의 극단적인 예: 더 이상 아무도 사용하지 않는 오래된 UNIX 메일 리더 중 하나가 구성 파일( )과 메일 폴더( ) elm를 보관하는 디렉터리를 만들기 전에 사용자의 승인을 요청합니다 . "아니요"라고 말하면 대답할 것입니다.~/.elm/~/Mail/
Very well, but you may run into difficulties later.
최근에 실행해 본 일부 프로그램(죄송합니다. 어떤 프로그램인지는 잊어버렸습니다)은 시작을 거부하고 문제가 무엇인지 전혀 알 수 없는 극단적인 결과를 보였습니다. strace이름이 지정된 디렉터리를 만들고 싶지만 ~/.config/해당 이름을 가진 일반 파일이 있기 때문에 만들 수 없다는 것을 보여줍니다. (한번은 cp .config ~커널 소스 트리에서 이 작업을 수행했기 때문에 백업이 있었습니다.) 분명히 이제는 알림(승인은 고사하고)이나 최소한의 오류 확인도 없이 사용자의 홈 디렉토리에 있는 매우 일반적인 이름을 밟는 것이 합리적이라고 간주됩니다.
진전.