Tại sao các bản vá bảo mật không được bao gồm trong Hạt nhân Vanilla?

22

Các lý do mà grsecuritycác bản vá (hoặc các tính năng bảo mật mà nó mang lại) không được bao gồm trong kernel theo mặc định. Khi nhìn vào những lợi ích cho bảo mật, có vẻ như hạt nhân vani khá không an toàn.

Nếu đây là một sự đánh đổi (một số ứng dụng mà bạn muốn tránh các biện pháp bảo mật), có vẻ như đó grsecuritycó thể là một tùy chọn để kích hoạt trong nhân vanilla.

Với rất nhiều thứ trong hạt nhân vani chính thống, tôi có một thời gian khó hiểu lý do tại sao cộng đồng không muốn bao gồm grsecurity.

linux kernel grsecurity

— nhân loại
nguồn

Nó dường như là một vấn đề chính trị. Có vẻ như Torvalds nghĩ rằng một số bản vá của họ là rác. Đồng thời xem Tư vấn bảo mật Qualys - Stack Clash và các lỗ hổng CONFIG_VMAP_STACK khác, refcount_t UAF và phương thức bỏ qua Secure Boot / rootkit trong danh sách gửi thư OSS-Security.

Từ các đề xuất trong quá khứ về danh sách gửi thư điện tử hạt nhân, bản thân tôi và những người khác đã được đặt vào thùng Torvalds nhãn "điên". Vì vậy, nó không chỉ là những người lo lắng phải đối mặt với vấn đề. Cũng thấy ngẫu nhiên: cảnh báo trình biên dịch im lặng và sửa chữa cuộc đua . Chủ đề này là một cuộc thảo luận về việc cung cấp một dmesg cho các trình điều khiển sử dụng {u} ngẫu nhiên trước khi sẵn sàng. (Bạn có thể không biết, nhưng một số trình điều khiển sử dụng các thiết bị trước khi chúng được gieo đúng cách. Hệ thống đã đọc từ urandom trước khi khởi tạo )

23

(Tôi là một nhà phát triển bảo mật.)

Câu trả lời của jsbillings dựa trên một bài đăng email được thảo luận trong một bài viết của LWN .

Bối cảnh quan trọng ở đây là không phải nhà phát triển bảo mật và nhà phát triển PaX không tham gia vào cuộc thảo luận danh sách gửi thư đó. Nhận xét của Nhóm PaX đối với bài viết của LWN sẽ làm rõ điều này. Chúng tôi chưa bao giờ gửi các bản vá để đưa vào dòng chính. Một lý do đơn giản là chúng tôi là những người có ý tưởng và triển khai, mà việc ngược dòng sẽ không giải quyết được. Hơn nữa, chúng tôi phải tham gia vào các đối số danh sách gửi thư mệt mỏi với một nhóm các nhà phát triển có khả năng chống bảo mật rất cao (xem bản trình bày H2HC 2012 của tôiđể thảo luận thêm về điều này). Chúng tôi có giới hạn thời gian và nguồn lực, vì vậy chúng tôi chọn sử dụng nó theo cách hiệu quả nhất có thể: tạo ra công nghệ bảo mật của ngày mai và cung cấp miễn phí cho mọi người. Như Nhóm PaX đề cập trong nhận xét của họ, chúng tôi có một quan điểm bao quát cụ thể về bảo mật và do đó không tin rằng có nhiều công đức trong việc phân tách và ngược dòng các tính năng riêng lẻ.

— Brad Spengler
nguồn

Tôi thích liên kết đến bài viết thú vị của LWN. Cảm ơn bạn. Tôi vẫn còn trong tình trạng bối rối khi đọc ý kiến rằng một nhóm các nhà phát triển Kernel sẽ "chống bảo mật rất nhiều". Tất nhiên tôi không có bất kỳ loại hiểu biết nào, nhưng điều này có vẻ đáng lo ngại :(. Sự nhầm lẫn là tôi cho rằng bảo mật là một trong những "đối số mạnh nhất" đối với OpenSource và Linux. Hiện tại tôi cảm thấy khá bị đe dọa trên hệ thống dựa trên Ubuntu của mình. Vẫn còn một chút bị bỏ lại phía sau, điều gì sẽ là "nhiều mắt hơn" - sự an toàn của hệ điều hành nếu chúng ta không biết gì? Tôi thích sự an toàn dù sao đi nữa, cảm ơn bạn vì điều đó

— nhân

10

Có vẻ như các nhà phát triển bảo mật đã có vấn đề trong quá khứ thuyết phục Linus chấp nhận thay đổi vào kernel. Các vấn đề dường như là:

Gửi một đốm mã khổng lồ và không phá vỡ nó thành từng mảnh
Linus xem xét rất nhiều thay đổi "điên rồ", có lẽ đó là cách nói của Linus rằng nó không hoạt động với các kế hoạch phát triển trong tương lai của anh ấy.

— jsbillings
nguồn

Đây là một số điểm xen kẽ. Vẫn đang học - Tôi thậm chí còn không biết về BLOB (đó là một thứ dữ liệu nhị phân, phải, một thứ không phải là nguồn mở tôi đoán). Vâng Thông tin là tốt. Nếu những lý do được nêu là đúng thì đó vẫn là một sự xấu hổ. Tôi thích ý tưởng về cải tiến bảo mật liên quan đến bản vá lỗi bảo mật.

— nhân loạiANDpeace

1

@humanityANDpeace "blob" có thể có nghĩa là "đối tượng lớn nhị phân" (thường theo nghĩa cơ sở dữ liệu, nhưng đôi khi cũng ở nơi khác), hoặc nó có thể là tiếng lóng cho "khối lớn của bất cứ điều gì". Trong trường hợp này, tôi lấy nó là jsbillings có nghĩa là cái sau: một đoạn mã nguồn lớn không được chia nhỏ hơn nữa. Là một lập trình viên, tôi biết chính xác những người có thể làm việc với họ như thế nào, chứ đừng nói đến việc xem xét.

— một CVn