Những ngôn ngữ nào ngoài Java có các mô hình bảo mật cho mã không có đặc quyền so với đặc quyền?

Question

Gần đây tôi đã học về mô hình bảo mật của Java. Hầu hết mọi người nghĩ rằng Java là an toàn bởi vì nó miễn dịch với tràn bộ đệm, vv, nhưng có toàn bộ mô hình bảo mật Java này tập trung xung quanh việc kiểm tra xem mã có quyền thực hiện một số hành động nhất định hay không. Họ thực sự giải quyết một vấn đề khó khăn: làm thế nào để cho phép mã không đáng tin cậy (nói trong một trình duyệt web) chạy nhưng bị ngăn cản truy cập vào hệ thống cơ bản theo những cách độc hại trong khi vẫn duy trì khả năng tương tác với hệ thống theo một số cách.

Sandboxed C++ hoặc một cái gì đó như thế sẽ rất khó để thử bởi vì ngôn ngữ quyết định rằng bạn có thể làm số học con trỏ, vv, cho phép mã độc hại làm hỏng các phần khác của quá trình. Vì có nhiều ngôn ngữ an toàn cho bộ nhớ, tuy nhiên, tôi đã tự hỏi những ngôn ngữ khác có các mô hình bảo mật phức tạp và cách chúng so sánh với các ngôn ngữ Java.

Tôi không biết có bao nhiêu ngôn ngữ cố gắng có khái niệm như "hộp cát", v.v. Tôi đang tìm một số gợi ý để tìm hiểu về hướng đi thú vị này của bảo mật máy tính.

Answer 1

Perl có một tính năng thực sự gọn gàng được gọi là chế độ taint (-T). Với chế độ đó được kích hoạt, bất kỳ biến nào đến từ thế giới bên ngoài (env vars, GET/POST data, vv) đều bị nhiễm độc, và bất kỳ biến nào chạm vào biến bị nhiễm độc cũng bị nhiễm độc. Các biến bị ô nhiễm không thể được sử dụng trong các phương thức liên lạc với thế giới bên ngoài (SQL, exec/system, v.v.). Cách duy nhất để untaint một biến là làm một regex trên nó; bất kỳ nhóm phù hợp nào đều không bị ô nhiễm. Tất nhiên, bạn có thể đi quanh chế độ taint bằng cách thực hiện regex cho /(.*)/, nhưng ý tưởng là bạn phải chủ động viết mã xấu như thế - thay vì chỉ bất cẩn quên khử trùng đầu vào của bạn - nếu bạn định làm một cái gì đó câm như concatting người dùng đầu vào thẳng vào MySQL.

Answer 2

E programming language được dựa trên capability security model trong đó quyền truy cập vào các đối tượng, có thể được phân phối trên các hệ thống khác nhau, chỉ khả dụng thông qua "khả năng" rõ ràng mà chương trình phải quản lý. Các đặc quyền duy nhất một đoạn mã là các quyền được truyền qua thông qua các khả năng của "nhà sản xuất" của nó khi nó được khởi tạo. Ý tưởng là dành cho một powerbox shell để cấp đặc quyền cho các đoạn mã khi chúng thực thi.

gì một chút ngạc nhiên là điều này cũng tương tự như Erlangđồng thời nguyên thủy - khả năng liên hệ với một quá trình đòi hỏi Erlang biết pid của tiến trình - có nghĩa là một quá trình cấp đặc quyền bởi giao tiếp pid. (Tất nhiên, Erlang cũng có có registered processes, có thể được gọi theo tên và Erlang cũng sử dụng một simple cookie scheme để truy cập hệ thống từ xa và truy cập vào thực thi các lệnh IO cơ bản trên các nút từ xa không bị khóa. Erlang trừ đi một vài tính năng có thể dễ dàng là một môi trường thực thi hộp cát không thể tin được, nhưng tôi không biết phải mất bao nhiêu công sức để loại bỏ các tính năng đó.)

Ruby also has a Taint environment, tương tự Perl's Taint environment as described by yshavit.

Tôi có tin tưởng vào bất kỳ hệ thống nào trong số này để thực thi mã độc hại không? Chắc là không.

Có các môi trường như được xây dựng bởi codepad.org để hạn chế việc thực thi mã không tin cậy bằng cách sử dụng active debugging facilities. Chúng cũng hữu ích, nhưng tôi cũng không chắc chắn tôi sẽ tin tưởng bao xa cả chúng.Tôi muốn tin tưởng một cái gì đó giống như QEMU+KVM/VMWare/Xen hơn, hoặc OpenVZ/vServers, hoặc một công cụ mandatory access control như AppArmor, SELinux, TOMOYO, hoặc SMACK. (Tôi đã làm việc trên AppArmor trong hơn một thập kỷ, vì vậy tôi hơi thiên về nó như một giải pháp cho nhiều người. Những người khác là những công cụ tốt có ý nghĩa hơn cho các triển khai khác nhau.)