Có một shell nào kiểm tra để đảm bảo mã được ký không?


19

Tôi đã loay hoay với PowerShell tuần này và phát hiện ra rằng bạn bắt buộc phải Ký các tập lệnh của mình để chúng có thể được chạy. Có bất kỳ chức năng bảo mật tương tự nào trong Linux liên quan đến việc ngăn các tập lệnh bash được chạy không?

Chức năng duy nhất tương tự như thế này, mà tôi biết là SSH yêu cầu một khóa nhất định.


2
Nghe có vẻ giống như một giải pháp đặc biệt để ký hợp đồng với tôi. Tôi không biết nếu Windows có gói mật mã ký theo cách Linux có.
tự đại diện

6
@ leeand00 Kịch bản là trường hợp đặc biệt của gói phần mềm và tôi không thể thấy bất kỳ điểm nào để xử lý trường hợp đó.
Gilles 'SO- ngừng trở nên xấu xa'

2
Cơ chế tôi thích nhất là cách ChromeOS thực hiện điều này - đặt hệ thống tệp duy nhất không được gắn cờ noexectrên phân vùng chỉ đọc trên thiết bị khối có chữ ký dm-verity.
Charles Duffy

1
source.android.com/security/verifiedboot nói về việc áp dụng tính năng đó (ban đầu là ChromeOS) của Android.
Charles Duffy

1
Bạn có thể coi bash là một loạt các lệnh có thể được gõ thủ công trong giao diện dòng lệnh. Điểm nào để hạn chế các tập lệnh khi bạn có thể nhập nội dung trong dòng lệnh?
Đinh-Yi Chen

Câu trả lời:


11

Nếu bạn đang khóa khả năng chạy tập lệnh của người dùng sudothì bạn có thể sử dụng digestchức năng.
Bạn có thể chỉ định hàm băm của tập lệnh / tệp thực thi sudoerssẽ được xác minh sudotrước khi được thực thi. Vì vậy, mặc dù không giống như ký, nhưng nó mang lại cho bạn một sự đảm bảo cơ bản rằng tập lệnh ít nhất không bị sửa đổi mà không có sudoers cũng được sửa đổi.

Nếu tên lệnh được tiền tố bằng Digest_Spec, lệnh sẽ chỉ khớp thành công nếu có thể được xác minh bằng cách sử dụng thông báo SHA-2 được chỉ định. Điều này có thể hữu ích trong trường hợp người dùng gọi sudo có quyền truy cập ghi vào lệnh hoặc thư mục mẹ của nó. Các định dạng digest sau được hỗ trợ: sha224, sha256, sha384 và sha512. Chuỗi có thể được chỉ định ở định dạng hex hoặc base64 (base64 nhỏ gọn hơn). Có một số tiện ích có khả năng tạo ra các bản tóm tắt SHA-2 ở định dạng hex như openssl, shasum, sha224sum, sha256sum, sha384sum, sha512sum.

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


Điều đó sẽ giữ tôi lại cho đến khi tôi đọc về SE Linux và làm điều đó đúng.
leeand00

13

Có và không.

Phân phối phần mềm Linux hoạt động hơi khác so với phân phối phần mềm Windows. Trong thế giới Linux (không nhúng), phương pháp chính để phân phối phần mềm là thông qua phân phối (Ubuntu, Debian, RHEL, Fedora, Arch, v.v.). Tất cả các bản phân phối chính đã ký các gói của họ một cách có hệ thống trong khoảng một thập kỷ.

Khi phần mềm được phân phối độc lập, tùy thuộc vào nhà cung cấp quyết định họ sẽ vận chuyển phần mềm của họ như thế nào. Các nhà cung cấp tốt cung cấp các nguồn gói tương thích với các bản phân phối chính (không có cơ chế phân phối thống nhất cho tất cả Linux: phân phối phần mềm là một trong những điểm khác biệt chính giữa các bản phân phối) và được ký với khóa của nhà cung cấp. Các bản phân phối Linux hiếm khi đóng vai trò là cơ quan ký kết cho các nhà cung cấp bên thứ ba (Canonical thực hiện điều này với các đối tác Ubuntu, nhưng điều đó bao gồm rất ít nhà cung cấp) và tôi nghĩ rằng tất cả các bản phân phối chính đều sử dụng web tin cậy PGP thay vì cơ sở hạ tầng khóa công khai TLS, vì vậy tùy thuộc vào người dùng để tìm hiểu xem họ có muốn tin vào một khóa hay không.

Không có cơ chế đặc biệt nào loại bỏ các gói phần mềm bao gồm một tập lệnh từ các gói phần mềm bao gồm tệp thực thi gốc, tệp dữ liệu hoặc nhiều tệp. Cũng không có bất kỳ xác minh chữ ký nào được tích hợp trong bất kỳ trình thông dịch tập lệnh phổ biến nào, bởi vì việc xác minh gói phần mềm là mối quan tâm hoàn toàn trực giao từ việc chạy tập lệnh.

Tôi nghĩ rằng Windows chú thích các tệp có nguồn gốc của chúng và yêu cầu xác nhận của người dùng để chạy một tệp có nguồn gốc là Tải xuống, chứ không phải là cục bộ. Linux không thực sự có một cơ chế tương tự. Điều gần nhất là quyền thực thi: một tệp đã tải xuống không có quyền thực thi, người dùng cần kích hoạt nó một cách rõ ràng ( chmod +xtrên dòng lệnh hoặc hành động tương đương trong trình quản lý tệp).


2
FWIW, trên PowerShell này có thể được định cấu hình (bằng cài đặt chính sách) để chỉ thực thi các tập lệnh đã ký và chính sách này có thể được cấu hình để tất cả các tập lệnh phải được ký hoặc chỉ các tập lệnh "nguồn gốc từ xa" hoặc không có tập lệnh. Nó hoạt động tốt nhất trong môi trường AD với quản lý chính và quản lý chính sách trung tâm. Có thể bỏ qua :-)
Stephen Harris

@StephenHarris Vâng, nếu bạn đặt nó để vượt qua ...
leeand00

@ leeand00 - Rõ ràng mã hóa base64 cũng hoạt động như một đường vòng nhưng tôi không biết liệu điều đó có bị đóng trong các phiên bản mới hơn của PowerShell không.
Stephen Harris

1
@ leeand00 - xem darkoperator.com/blog/2013/3/5/ cho một số niềm vui :-) Về cơ bản vượt qua tập lệnh được mã hóa base64 làm tham số trên dòng lệnh :-) Đủ dễ dàng để trình bao bọc!
Stephen Harris

2
SeLinux chú thích các tập tin với nguồn gốc của chúng. Đây là một trong những cơ sở chính của nó.
loa_in_

10

Linux không cung cấp khả năng giới hạn việc thực thi các tập lệnh bash dựa trên chữ ký số.

Có một số công việc về xác thực thực thi nhị phân. Xem https://lwn.net/Articles/488906/ để biết thông tin.


Upvote cho câu trả lời trực tiếp mà không đề xuất một hackey làm việc xung quanh.
dùng394

8

Trong một từ, "không".

Linux không thực sự phân biệt giữa các tập tin thực thi và tập lệnh; những #!lúc đầu là một cách để nói với kernel những gì chương trình để chạy để đánh giá đầu vào, nhưng nó không phải là cách duy nhất một kịch bản có thể được thực thi.

Vì vậy, ví dụ, nếu tôi có một kịch bản

$ cat x
#!/bin/sh 
echo hello

Sau đó tôi có thể chạy nó với lệnh

$ ./x

Điều đó sẽ khiến kernel thử và thực thi nó, phát hiện ra #!và sau đó chạy một cách hiệu quả /bin/sh x.

Tuy nhiên tôi cũng có thể chạy bất kỳ biến thể nào trong số này:

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

hoặc thậm chí

. ./x

Vì vậy, ngay cả khi kernel đã cố thực thi việc ký ở execlớp, chúng ta có thể bỏ qua điều này bằng cách chỉ chạy trình thông dịch với tập lệnh làm tham số.

Điều này có nghĩa là việc ký mã sẽ phải nằm trong chính trình thông dịch. Và điều gì sẽ ngăn người dùng biên dịch bản sao của chính họ mà không cần mã thực thi ký?

Giải pháp tiêu chuẩn cho vấn đề này không phải là sử dụng ký, mà là sử dụng Kiểm soát truy cập bắt buộc (MAC), chẳng hạn như SELinux. Với các hệ thống MAC, bạn có thể chỉ định chính xác những gì mỗi người dùng được phép chạy và chuyển tiếp các lớp. Vì vậy, ví dụ, bạn có thể nói "người dùng bình thường có thể chạy bất cứ thứ gì ngoại trừ máy chủ web và quy trình CGI chỉ có thể truy cập nội dung từ /var/httpdthư mục; mọi thứ khác đều bị từ chối".


1
This means that signing code would have to be in the interpreter itself. And what would stop a user from compiling their own copy of a shell without the signing enforcement code?Không cho phép thực thi bất kỳ thực thi chưa ký nào sẽ làm điều đó, Nếu người dùng không có khóa ký. Có nhiều dự án * nix cho việc này rồi.
alzee

2

Các bản phân phối Linux thường có gnupg . Tôi nghe có vẻ như tất cả những gì bạn muốn là một trình bao bọc bash đơn giản kiểm tra chữ ký gpg tách rời so với tập lệnh đối số và chỉ tiến hành chạy tập lệnh nếu kiểm tra thành công:

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

Điều duy nhất mà hiện tại không có là chạy một kịch bản mà ai đó đã tự tạo ... một mình ...
leeand00

2

Câu hỏi ngược lại xuất hiện ngay lập tức là "Tại sao bạn muốn ngăn người dùng chạy các chương trình họ đã viết? " Một số khả năng tồn tại:

  1. Nghĩa đen là không thể phát hiện ra ai là tác giả của mã ở nơi đầu tiên. Chủ sở hữu tệp tập lệnh chỉ là bất kỳ ai thực sự lưu nội dung của tệp đó, bất kể nó đến từ đâu. Vì vậy, việc thi hành chữ ký chỉ là một thay thế phức tạp cho hộp thoại xác nhận: "Bạn có chắc chắn muốn làm điều này không?" Trong Linux, một phần của vấn đề này được giải quyết một cách minh bạch với các gói đã ký và được giảm nhẹ bởi thực tế là người dùng có quyền truy cập hạn chế theo mặc định. Người dùng cũng sẽ biết rằng việc chạy mã của người khác có thể nguy hiểm *.
  2. Trong cùng một ký, một tập lệnh là một hoạt động phức tạp hơn nhiều so với việc lưu một tập tin. Trong trường hợp tốt nhất, điều này nhắc nhở người dùng nhận ra rằng họ đang thực hiện một hành động tương tự như ký một tài liệu và nên kiểm tra những gì nó nói trước khi tiếp tục. Nhiều khả năng nó chỉ đơn giản là đảm bảo mức độ thành thạo kỹ thuật rất tối thiểu từ phía người dùng được phép chạy tập lệnh. Trong trường hợp xấu nhất nó cho thấy sự sẵn sàng để nhảy qua một chuỗi dài các hoops để chạy những gì họ muốn. Thành thạo kỹ thuật được giả định trên Linux *.
  3. Nhiều khả năng mọi người sẽ phát hiện mã độc rõ ràng khi gõ / dán một loạt lệnh vào dòng lệnh của họ. Đoạn mã có nghĩa là được sao chép và dán thường nhỏ hơn chuỗi lệnh cần thiết để làm một cái gì đó bất chính. Người dùng cũng có thể cẩn thận sao chép và dán từng dòng riêng biệt, hiểu những gì xảy ra khi nó xảy ra. Với một kịch bản, có thể người dùng chưa bao giờ nhìn vào mã. Đây có thể là một ứng dụng hữu ích của các tập lệnh đã ký, với chi phí quá phổ biến cho sự tự mãn sau lần thứ 12 bạn phải làm điều đó.

* Điều này có lẽ ngày càng trở nên ít đúng khi nhiều người bắt đầu sử dụng Linux


1

Lý do các hệ thống đã phát triển khác nhau là Linux có thuộc tính tệp 'exec' và Windows sử dụng các phần mở rộng tệp để xác định khả năng thực thi.

Vì vậy, trong Windows, thật dễ dàng để lừa người dùng tải xuống một tệp có phần mở rộng ".exe", ".bat", ".scr", sẽ bị ẩn theo mặc định . Bấm đúp vào tệp đó sẽ cung cấp cho bạn thực thi mã tùy ý. Do đó, một cơ chế lớn về theo dõi nguồn gốc và thực thi / ký tập lệnh đã được xây dựng để giảm thiểu rủi ro này.

Trên Linux, bạn có thể có được một tệp cho người dùng, nhưng bạn không thể dễ dàng buộc bit 'exec' được đặt. Ngoài ra, có thể làm cho toàn bộ hệ thống tập tin 'noexec'.

Trong mọi trường hợp, bạn có thể chạy một kịch bản một cách rõ ràng bằng cách gọi trình thông dịch. Bạn thậm chí có thể tạo các tập lệnh shell trong thời gian chạy và chuyển chúng thành "sh" hoặc chạy "sh -c".


0

Theo tùy chỉnh, nhiều chương trình lưu trữ không bảo toàn bit thực thi trên các tệp được chứa. Điều này làm cho nó không thể chạy các thực thi tùy ý. Cũng gần như vậy.

Vấn đề là, những gì đã được mô tả trong một câu trả lời khác rằng việc thiếu bit thực thi không ngăn bạn chuyển trực tiếp tập lệnh như vậy sang bash. Mặc dù người ta cho rằng hầu hết các tập lệnh như vậy là bashtập lệnh, shebang có thể chỉ định bất kỳ chương trình nào làm thông dịch viên. Điều này có nghĩa là tùy thuộc vào người dùng để chạy trình thông dịch phù hợp nếu họ quyết định bỏ qua ngữ nghĩa thực thi.

Mặc dù điều này không nhiều, nhưng điều này bao gồm rất nhiều việc ngăn chặn việc chạy các tệp thực thi không đáng tin cậy trên * nixes chỉ với kernel và shell .

Như tôi đã đề cập trong một trong các ý kiến, có một lớp bảo vệ khác - SeLinux- theo dõi nguồn gốc của các tệp dựa trên một bộ quy tắc. SeLinuxVí dụ, một thiết lập sẽ không cho phép root chạy một tệp thực thi với tập bit thực thi được tải xuống từ internet, ngay cả khi bạn sao chép và di chuyển tệp xung quanh. Người ta có thể thêm một quy tắc rằng các tệp như vậy chỉ có thể được chạy qua một tệp nhị phân khác sẽ kiểm tra chữ ký, không giống như những gì bạn đã đề cập trong câu hỏi của mình.

Vì vậy, cuối cùng, vấn đề cấu hình của các công cụ thường được cài đặt sẵn và câu trả lời là .


nhiều chương trình lưu trữ không bảo toàn bit thực thi trên các tệp chứa .. tốt, đó là một điểm chấp khi bạn thực sự muốn sử dụng nó để lưu trữ. May mắn thay tar không bảo toàn bit thực thi.
pjc50

Bạn phải sử dụng tar -p nguồn
loa_in_

-p, --preserve-permissions, --same-permissionscó nghĩa là trích xuất thông tin về quyền truy cập tệp (mặc định cho siêu người dùng)
loa_in_

Không, bạn KHÔNG cần -p. Tôi thấy những gì trang người đàn ông nói, nhưng nó không phải là những gì xảy ra. touch permtest; chmod +x permtest; tar cf permtest.tar.gz permtest; rm permtest; tar xf permtest.tar.gz; ls -l permtest- nó có thể thực thi được ở đây và tôi không root.
Domen

Tôi sẽ cố gắng cải thiện câu trả lời của tôi sau đó.
loa_in_
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.