코드가 서명되었는지 확인하는 쉘이 있습니까?

이번 주 PowerShell을 엉망으로 만들었고 스크립트를 실행할 수 있도록 스크립트에 서명해야한다는 것을 알았습니다. Linux에서 bash 스크립트 실행 방지와 관련된 유사한 보안 기능이 있습니까?

내가 아는 유일한 기능은 특정 키가 필요한 SSH의 기능입니다.

스크립트를 실행하는 사용자의 기능을 잠그는 경우 기능을 sudo사용할 수 있습니다 digest.
실행 하기 전에 sudoers확인할 스크립트 / 실행 파일의 해시를 지정할 수 있습니다 sudo. 따라서 서명과 동일하지는 않지만 sudoers도 수정하지 않고 스크립트가 수정되지 않았다는 기본 보증을 제공합니다.

명령 이름 앞에 Digest_Spec이 붙은 경우 지정된 SHA-2 다이제스트를 사용하여 확인할 수있는 경우에만 명령이 성공적으로 일치합니다. sudo를 호출하는 사용자가 명령 또는 상위 디렉토리에 대한 쓰기 액세스 권한을 가지고있는 상황에서 유용 할 수 있습니다. sha224, sha256, sha384 및 sha512와 같은 다이제스트 형식이 지원됩니다. 문자열은 16 진 또는 base64 형식으로 지정할 수 있습니다 (base64가 더 간결합니다). openssl, shasum, sha224sum, sha256sum, sha384sum, sha512sum과 같이 16 진수 형식으로 SHA-2 다이제스트를 생성 할 수있는 여러 유틸리티가 있습니다.

http://www.sudo.ws/man/1.8.13/sudoers.man.html

예, 아니오

Linux 소프트웨어 배포는 Windows 소프트웨어 배포와 약간 다르게 작동합니다. (내장되지 않은) Linux 세계에서 소프트웨어를 배포하는 기본 방법은 배포판 (우분투, 데비안, RHEL, 페도라, 아치 등)을 사용하는 것입니다. 모든 주요 배포판은 약 10 년 동안 패키지에 체계적으로 서명했습니다.

소프트웨어가 독립적으로 배포 될 때 소프트웨어를 어떻게 배송할지 결정하는 것은 공급 업체의 책임입니다. 좋은 공급 업체는 주요 배포판과 호환되는 패키지 소스를 제공합니다 (모든 Linux에 대해 통합 배포 메커니즘이 없습니다 : 소프트웨어 배포는 배포판의 차별화의 주요 지점 중 하나임). 그리고 공급 업체의 키로 서명됩니다. Linux 배포판은 타사 공급 업체의 서명 기관으로 거의 작동하지 않으며 (Canonical은 우분투 파트너와 함께이 작업을 수행하지만 공급 업체는 거의 없습니다) 모든 주요 배포판은 TLS 공개 키 인프라가 아닌 PGP 신뢰 웹을 사용한다고 생각합니다. 키를 신뢰하는지 여부는 사용자에게 달려 있습니다.

기본 실행 파일, 데이터 파일 또는 여러 파일로 구성된 소프트웨어 패키지에서 단일 스크립트로 구성된 소프트웨어 패키지를 단일화하는 특별한 메커니즘은 없습니다. 소프트웨어 패키지 확인은 스크립트를 실행하는 데있어 완전히 직교하는 문제이므로 일반적인 스크립트 인터프리터에 서명 확인도 내장되어 있지 않습니다.

Windows는 원본으로 파일에 주석을 달고 원본이 "local"이 아닌 "download"인 파일을 실행하려면 사용자 확인이 필요하다고 생각합니다. 리눅스에는 실제로 비슷한 메커니즘이 없습니다. 가장 가까운 것은 실행 권한입니다. 다운로드 한 파일에는 실행 권한이 없으므로 사용자는 명시 적으로 파일을 활성화해야합니다 ( chmod +x명령 줄에서 또는 파일 관리자에서 동등한 작업).

Linux는 디지털 서명을 기반으로 bash 스크립트의 실행을 제한하는 기능을 제공하지 않습니다.

바이너리 실행 파일을 인증하는 작업이 있습니다. 자세한 내용은 https://lwn.net/Articles/488906/ 을 참조 하십시오 .

한마디로 "아니오".

리눅스는 실제로 실행 파일과 스크립트를 구분하지 않습니다. #!처음에 입력을 평가하기 위해 실행하는 어떤 프로그램이 커널을 알 수있는 방법이지만 스크립트가 실행될 수있는 유일한 방법이 아니다.

예를 들어 스크립트가 있다면

$ cat x
#!/bin/sh 
echo hello

그런 다음 명령으로 이것을 실행할 수 있습니다

$ ./x

이렇게하면 커널이이를 시도하고 실행하여를 발견 한 #!다음 효과적으로 실행하게 /bin/sh x됩니다.

그러나 다음과 같은 변형 도 실행할 수 있습니다 .

$ sh ./x
$ bash ./x
$ cat x | sh
$ cat x | bash
$ sh < x

또는

. ./x

따라서 커널이 exec레이어 에서 서명을 시도하더라도 스크립트를 매개 변수로 사용하여 인터프리터 만 실행하여이를 무시할 수 있습니다.

이는 서명 코드가 인터프리터 자체에 있어야 함을 의미합니다. 그리고 서명 시행 코드 없이 사용자가 자신의 쉘 사본을 컴파일하지 못하게하는 이유는 무엇 입니까?

이에 대한 표준 솔루션은 서명을 사용하는 것이 아니라와 같은 필수 액세스 제어 (MAC)를 사용하는 것 SELinux입니다. MAC 시스템을 사용하면 각 사용자가 레이어를 실행하고 전환 할 수있는 대상을 정확하게 지정할 수 있습니다. 예를 들어 "일반 사용자는 웹 서버와 CGI 프로세스가 /var/httpd디렉토리의 항목 에만 액세스 할 수 있지만 다른 모든 항목은 거부됩니다"라는 것을 말할 수 있습니다 .

리눅스 배포판에는 보통 gnupg가 있습니다. 인수 스크립트에서 분리 된 gpg 서명을 검사하고 검사가 성공하면 스크립트를 계속 실행하는 간단한 bash 래퍼 인 것처럼 들립니다.

#!/bin/sh
gpgv2 $1.asc && bash "$@"

즉각적인 반론은 "사용자가 작성한 프로그램 을 사용자가 실행하지 못하게하려는 이유는 무엇 입니까? "입니다.

1. 처음에 누가 코드를 작성했는지 감지 하는 것은 사실상 불가능합니다 . 스크립트 파일의 소유자는 파일의 출처에 관계없이 해당 파일의 내용을 실제로 저장 한 사람입니다. 따라서 서명을 시행하는 것은 확인 대화 상자를 대체 하는 복잡한 대안 일뿐 입니다. "정말로 하시겠습니까?" Linux에서이 문제의 일부는 서명 된 패키지를 사용하여 투명하게 해결되며 사용자가 기본적으로 액세스가 제한되어 있다는 사실로 완화됩니다. 또한 사용자는 다른 사람의 코드를 실행하는 것이 위험 할 수 있음을 알고 있어야합니다 *.
2. 같은 맥락에서 스크립트 서명은 파일을 저장하는 것보다 훨씬 복잡한 작업입니다. 가장 좋은 경우, 이는 사용자에게 문서 서명과 유사한 작업을 수행하고 있음을 인식하도록하며 계속하기 전에 해당 내용을 검사해야합니다. 대부분 사용자가 스크립트를 실행할 수 있도록 최소한의 기술 숙련도 를 보장합니다 . 최악의 경우, 그들이 원하는 것을 달리기 위해 일련의 긴 후프 를 뛰어 넘을 의지를 보여줍니다 . 기술 능력은 Linux *에서 가정됩니다.
3. 일련의 명령을 명령 줄에 입력 / 붙여 넣을 때 사람들이 분명히 악성 코드 를 탐지 할 가능성이 높습니다 . 일반 텍스트 스 니펫은 복사하여 붙여 넣어야하는 것으로 보통 사악한 작업을 수행하는 데 필요한 일련의 명령보다 작습니다. 또한 사용자는 모든 행을 개별적으로 신중하게 복사하여 붙여 넣을 수 있으며 발생하는 상황을 이해할 수 있습니다. 스크립트를 사용하면 사용자가 코드를 전혀 보지 못했을 수 있습니다. 이것은 12 번째 시간이 지나면 너무 일반적인 비용으로 서명 된 스크립트를 유용하게 적용 할 수 있습니다.

* 더 많은 사람들이 리눅스를 사용하기 시작함에 따라 이것은 아마도 점점 더 진실이되지 않을 것입니다

시스템이 다르게 진화 한 이유는 Linux에 'exec'파일 속성이 있고 Windows가 파일 확장자를 사용하여 실행 가능성을 판별하기 때문입니다.

따라서 Windows에서는 ".exe", ".bat", ".scr"확장명을 가진 파일을 다운로드하도록 사용자를 속이기 쉽습니다 . 기본적으로 숨겨져 있습니다 . 해당 파일을 두 번 클릭하면 임의 코드가 실행됩니다. 따라서 이러한 위험을 완화하기 위해 대규모 원산지 추적 및 실행 / 스크립트 서명 메커니즘이 구축되었습니다.

Linux에서는 사용자에게 파일을 가져올 수 있지만 'exec'비트를 쉽게 설정할 수는 없습니다. 또한 전체 파일 시스템을 'noexec'로 만들 수 있습니다.

어떤 경우에도 인터프리터를 호출하여 스크립트를 명시 적으로 실행할 수 있습니다. 런타임에 쉘 스크립트를 작성하여 "sh"로 파이프하거나 "sh -c"를 실행할 수도 있습니다.

사용자 지정에 따라 많은 보관 프로그램은 포함 된 파일의 실행 비트를 유지하지 않습니다. 이로 인해 임의의 실행 파일을 실행할 수 없습니다. 거의 요

요점은, 실행 비트가 없다고해서 그런 스크립트를로 직접 전달하는 것을 방해하지 않는다는 또 다른 대답에서 설명한 것입니다 bash. 그러한 스크립트는 대부분 스크립트라고 할 수 있지만 bashshebang은 모든 프로그램을 인터프리터로 지정할 수 있습니다. 즉, 실행 가능한 의미론을 무시하기로 결정한 경우 적절한 인터프리터를 실행하는 것은 사용자의 몫입니다.

이것이 많지는 않지만 이것은 커널과 쉘만으로 * nixes에서 신뢰할 수없는 실행 파일을 실행하지 못하게하는 것을 거의 다룹니다 .

주석 중 하나에서 언급했듯이 다른 보호 계층이 있습니다.이 계층 SeLinux은 규칙 세트를 기반으로 파일의 출처를 추적합니다. 세트 업 SeLinux예를 들어 복사 주위에 파일을 이동하더라도 루트가 인터넷에서 다운로드 한 실행 비트 세트가있는 실행 파일을 실행하는 것을 허용하지 않을 것입니다. 질문에서 언급 한 것과 달리 서명을 확인하는 다른 바이너리를 통해서만 이러한 파일을 실행할 수 있다는 규칙을 추가 할 수 있습니다.

결국에는 일반적으로 사전 설치된 도구의 구성 문제이며 그 대답은 yes 입니다.