Kees Cook, cựu quản trị viên hệ thống của kernel.org và lãnh đạo Nhóm bảo mật Ubuntu, hiện đang làm việc tại Google để bảo mật Android và ChromeOS, bày tỏ lo ngại về quy trình sửa lỗi hiện tại trong các nhánh ổn định của kernel. Mỗi tuần, khoảng một trăm bản sửa lỗi được đưa vào các nhánh ổn định và sau khi đóng cửa sổ chấp nhận thay đổi trong bản phát hành tiếp theo, nó sẽ đạt tới một nghìn bản sửa lỗi (người bảo trì giữ các bản sửa lỗi cho đến khi cửa sổ đóng lại và sau khi hình thành “ -rc1” họ xuất bản những cái tích lũy cùng một lúc), quá nhiều và đòi hỏi nhiều lao động để bảo trì các sản phẩm dựa trên nhân Linux.
Theo Keys, quá trình xử lý các lỗi trong kernel không được quan tâm đúng mức và kernel thiếu ít nhất 100 nhà phát triển bổ sung để phối hợp làm việc trong lĩnh vực này. Các nhà phát triển kernel chính thường xuyên sửa lỗi, nhưng không có gì đảm bảo rằng những bản sửa lỗi này sẽ được chuyển sang các biến thể kernel được bên thứ ba sử dụng. Người dùng các sản phẩm khác nhau dựa trên nhân Linux cũng không có cách nào để kiểm soát lỗi nào đã được sửa và nhân nào được sử dụng trong thiết bị của họ. Cuối cùng, các nhà sản xuất chịu trách nhiệm về tính bảo mật của sản phẩm của họ, nhưng với cường độ xuất bản các bản sửa lỗi rất cao trong các nhánh hạt nhân ổn định, họ phải đối mặt với một lựa chọn - chuyển tất cả các bản sửa lỗi, chuyển có chọn lọc những bản sửa lỗi quan trọng nhất hoặc bỏ qua tất cả các bản sửa lỗi. .
Giải pháp tối ưu là chỉ di chuyển các bản sửa lỗi và lỗ hổng quan trọng nhất, nhưng việc tách các lỗi đó khỏi quy trình chung là vấn đề chính. Phần lớn các vấn đề nảy sinh là hậu quả của việc sử dụng ngôn ngữ C, vốn đòi hỏi sự cẩn thận cao độ khi làm việc với bộ nhớ và con trỏ. Tệ hơn nữa, nhiều bản vá lỗ hổng tiềm ẩn không được cung cấp mã định danh CVE hoặc được gán mã định danh CVE một thời gian sau khi bản vá được xuất bản. Trong môi trường như vậy, các nhà sản xuất rất khó tách các bản sửa lỗi nhỏ khỏi các vấn đề bảo mật quan trọng. Theo thống kê, hơn 40% lỗ hổng được khắc phục trước khi chỉ định CVE và trung bình độ trễ từ khi phát hành bản sửa lỗi đến khi chỉ định CVE là ba tháng (tức là lúc đầu bản sửa lỗi được coi là một lỗi thông thường, nhưng chỉ sau vài tháng người ta mới biết rõ rằng lỗ hổng này đã được sửa).
Do đó, không có nhánh riêng biệt cung cấp các bản sửa lỗi cho các lỗ hổng và không nhận được thông tin về kết nối bảo mật của một sự cố cụ thể, các nhà sản xuất sản phẩm dựa trên nhân Linux sẽ phải liên tục chuyển tất cả các bản sửa lỗi từ các nhánh ổn định mới nhất. Nhưng công việc này đòi hỏi nhiều lao động và gặp phải sự phản kháng ở các công ty do lo ngại xuất hiện những thay đổi mang tính lũy thoái có thể làm gián đoạn hoạt động bình thường của sản phẩm.
Chúng ta hãy nhớ lại rằng theo Linus Torvalds, tất cả các lỗi đều quan trọng và không nên tách các lỗ hổng khỏi các loại lỗi khác và phân bổ vào một danh mục riêng biệt có mức độ ưu tiên cao hơn. Ý kiến này được giải thích là do đối với một nhà phát triển bình thường không chuyên về các vấn đề bảo mật, mối liên hệ giữa bản sửa lỗi và lỗ hổng tiềm ẩn là không rõ ràng (đối với nhiều bản sửa lỗi, chỉ có một cuộc kiểm tra riêng biệt mới có thể hiểu rằng chúng liên quan đến bảo mật. ). Theo Linus, các chuyên gia bảo mật từ các nhóm chịu trách nhiệm duy trì các gói kernel trong bản phân phối Linux nên tham gia vào việc xác định các lỗ hổng tiềm ẩn từ dòng bản vá chung.
Kees Cook tin rằng giải pháp duy nhất để duy trì tính bảo mật của nhân với chi phí dài hạn hợp lý là các công ty phải chuyển các kỹ sư liên quan đến việc chuyển các bản sửa lỗi sang các bản dựng nhân cục bộ thành một nỗ lực chung, phối hợp để duy trì các bản sửa lỗi và lỗ hổng trong nhân chính (ngược dòng). ). Ở dạng hiện tại, nhiều nhà sản xuất không sử dụng phiên bản kernel mới nhất trong sản phẩm của họ và cung cấp các bản sửa lỗi nội bộ, tức là. Hóa ra các kỹ sư ở các công ty khác nhau sao chép công việc của nhau để giải quyết cùng một vấn đề.
Ví dụ: nếu 10 công ty, mỗi công ty có một kỹ sư báo cáo lại các bản sửa lỗi giống nhau, phân công lại các kỹ sư đó để sửa lỗi ở tuyến trên, thì thay vì báo cáo lại một bản sửa lỗi, họ có thể sửa 10 lỗi khác nhau vì lợi ích chung hoặc tham gia đánh giá các đề xuất. thay đổi và ngăn chặn mã lỗi được đưa vào kernel. Các nguồn lực cũng có thể được dành để tạo ra các công cụ mới để kiểm tra và phân tích mã cho phép phát hiện sớm các loại lỗi phổ biến xuất hiện lặp đi lặp lại.
Kees Cook cũng đề xuất tích cực hơn bằng cách sử dụng thử nghiệm tự động và làm mờ trực tiếp trong quá trình phát triển hạt nhân, sử dụng các hệ thống tích hợp liên tục và từ bỏ việc quản lý phát triển cổ xưa qua email. Hiện tại, việc thử nghiệm hiệu quả đang bị cản trở bởi thực tế là các quy trình thử nghiệm chính bị tách khỏi quá trình phát triển và diễn ra sau khi các bản phát hành được hình thành. Keys cũng khuyến nghị sử dụng các ngôn ngữ cung cấp mức độ bảo mật cao hơn, chẳng hạn như Rust, khi phát triển để giảm số lượng lỗi.
Nguồn: opennet.ru