- Nhóm bảo mật nhân Linux sửa các lỗ hổng được báo cáo nhanh nhất có thể và hợp nhất vào kho lưu trữ công khai mà không đưa ra thông báo hay công bố riêng
- Nhóm này tách biệt với nhóm CVE của nhân phụ trách cấp CVE, tất cả đều hoạt động với tư cách cá nhân và được vận hành không phụ thuộc vào công ty chủ quản
- Lỗi bảo mật được xử lý giống hệt lỗi thông thường, và sau khi sửa sẽ không được đánh dấu là “bản vá bảo mật” riêng biệt
- Không duy trì embargo quá 7 ngày, và phần lớn bản sửa lỗi được công khai ngay lập tức
- Cách tiếp cận này phản ánh đặc tính mã nguồn mở và sự đa dạng của môi trường sử dụng, đồng thời duy trì tính minh bạch và độc lập trong ứng phó bảo mật của nhân
Vai trò của nhóm bảo mật nhân Linux
- Nhóm bảo mật nhân là nhóm nhà phát triển phân loại các lỗi bảo mật tiềm ẩn được báo cáo và sửa chúng nhanh chóng
- Họ phụ trách ứng phó bảo mật mang tính phản ứng (reactive), tách biệt với các biện pháp phòng ngừa dài hạn do Kernel Self-Protection Project thực hiện
- Quy trình báo cáo được thực hiện bằng email văn bản thuần túy đơn giản, không cho phép HTML, tệp đính kèm nhị phân hay mã hóa
- Báo cáo được mã hóa không thể xử lý do cấu trúc nhiều người nhận
- Thành viên nhóm là các nhà phát triển chủ chốt đại diện cho những phân hệ chính của nhân, và không được chia sẻ nội dung thảo luận với chủ lao động hoặc bên ngoài
- Nhờ tính độc lập này, họ có thể phản hồi nhất quán bất kể các yêu cầu pháp lý ở nhiều quốc gia khác nhau (như CRA)
Quy trình sửa lỗi
- Nếu lỗi được báo cáo liên quan đến một phân hệ cụ thể, họ sẽ giải quyết bằng cách đưa người bảo trì phân hệ đó vào cuộc thảo luận qua email
- Với các phân hệ thường xuyên phát sinh vấn đề, người bảo trì đôi khi tham gia trực tiếp vào mailing list của nhóm bảo mật
- Nếu người báo cáo cung cấp bản vá sửa lỗi thì sẽ được ghi nhận công lao; nếu không, các nhà phát triển sẽ tự giải quyết
- Khi hoàn tất, bản sửa sẽ được hợp nhất vào nhánh nhân chính và các bản phát hành ổn định (stable)
Chính sách embargo
- Không cho phép thời gian không công khai vượt quá 7 ngày, và phần lớn bản sửa lỗi được công khai ngay lập tức
- Sau khi sửa xong, người báo cáo chỉ có thể đưa ra thông báo bên ngoài nếu họ muốn, còn bản thân nhóm bảo mật không đưa ra bất kỳ công bố nào
- Việc gán CVE sau đó do nhóm CVE của nhân thực hiện, tách biệt với nhóm bảo mật
Nguyên tắc “lỗi chỉ là lỗi”
- Năm 2008, Linus Torvalds đã nêu rõ rằng không nên đánh dấu riêng lỗi bảo mật
- Lý do là việc phân biệt thành “bản sửa bảo mật” sẽ làm méo mó mức độ quan trọng của các lỗi khác
- Mọi bản sửa lỗi đều quan trọng như nhau, và đều được áp dụng ngay lập tức bất kể là bảo mật, chức năng hay hiệu năng
Vì sao không có thông báo bảo mật
- Gần như mọi lỗi ở cấp nhân đều có thể trở thành vấn đề bảo mật tiềm ẩn
- Chúng có thể xuất hiện dưới nhiều dạng như rò rỉ bộ nhớ, từ chối dịch vụ, rò rỉ thông tin...
- Do đặc tính mã nguồn mở, nhà phát triển không thể biết môi trường thực tế của người dùng
- Một bản sửa nhỏ với người này có thể là lỗ hổng nghiêm trọng với người khác
- Vì vậy chính sách rất đơn giản
- Lỗi đã biết thì sửa ngay
- Phát hành bản đã sửa nhanh nhất có thể
- Quan điểm của họ là thay vì lo ngại “bản sửa có thể gây ra vấn đề”, việc để một lỗi đã biết tồn tại còn nguy hiểm hơn
Vấn đề bảo mật phần cứng
- Các trường hợp như Spectre và Meltdown, vốn liên quan đồng thời đến hệ điều hành và phần cứng, cần quy trình ngoại lệ
- Vì vậy đã có ‘Hardware Security Policy’ để phối hợp qua mailing list mã hóa giới hạn
- Quy trình này chậm và phức tạp, nhưng gần đây nhiều lỗi phần cứng đã được giải quyết mà không cần qua quy trình này
- Trong tương lai, do yêu cầu về thời gian phản hồi của luật CRA, việc giữ bí mật dài hạn có thể sẽ còn khó hơn
Bối cảnh ra đời của nhóm bảo mật nhân
- Trước năm 2005, không tồn tại đầu mối liên hệ bảo mật chính thức
- Việc báo cáo chỉ diễn ra qua mạng lưới không chính thức giữa các nhà phát triển
- Năm 2005, cuộc thảo luận bắt đầu từ đề xuất qua email của Steve Bergman,
sau đó Chris Wright viết bản vá bổ sung đầu mối liên hệ và tài liệu bảo mật
- Từ đó, bí danh email trung tâm (security@kernel.org) được chính thức hóa
Không có thông báo bảo mật hay cảnh báo sớm
- Nhóm bảo mật nhân không vận hành bất kỳ hình thức thông báo bảo mật hay danh sách cảnh báo sớm nào
- Việc gán CVE ID do nhóm CVE của nhân phụ trách, nhóm bảo mật không tham gia
- Dù có nhiều yêu cầu về danh sách cảnh báo sớm, nó vẫn không tồn tại vì rủi ro rò rỉ và nguyên tắc tính công khai
- Quan điểm của họ là: “nếu chính phủ có thể cho phép điều đó, thì dự án đó có lẽ trên thực tế không được sử dụng”
1 bình luận
Ý kiến trên Hacker News
Gần đây, các công nghệ giúp trải nghiệm ảo hóa trên Linux desktop trở nên mượt mà đang phát triển rất nhanh
Trình điều khiển GPU hỗ trợ native context thông qua Mesa, và tính năng chia sẻ giữa guest–host của Wayland cũng đang được cải thiện
Trước đây cần những phần phân tích giao thức phức tạp như sommelier hay wayland-proxy-virtwl, nhưng giờ dự án wl-cross-domain-proxy đang triển khai việc này một cách bài bản
Các VMM tận dụng những tính năng này gồm có muvm, và giải pháp tích hợp chúng lại là munix
Nếu có thể tạm dừng, chuyển đi rồi tiếp tục lại máy ảo thì sẽ rất hay
Đây là lý do Red Hat vẫn còn quan trọng ngay cả trong năm 2025
Kiểu công việc hạ tầng như thế này lúc nào cũng cần thiết
Khi Red Hat chọn lọc các commit bảo mật để cherry-pick, nếu upstream không nói commit nào liên quan đến bảo mật thì họ biết bằng cách nào?
Thỉnh thoảng tôi mơ về một OS an toàn tuyệt đối 100%
Có lẽ formal verification hoặc Rust sẽ là chìa khóa
Tôi muốn có cảm giác chắc chắn rằng mình sẽ không bị hack
Suy cho cùng, con người mới là lỗ hổng lớn nhất
Thậm chí họ còn kiểm chứng cả assembly, và Dafny cũng ra đời từ đó
Nhưng trên thị trường, ‘triển khai nhanh’ được ưu tiên hơn ‘chất lượng tốt’, nên để ý tưởng này trở thành chủ lưu có lẽ còn mất vài chục năm nữa
Muốn cách ly thực sự thì cần ảo hóa hoặc tách biệt vật lý
Vì vậy sẽ khó thu hút nhiều người đóng góp cho một “OS an toàn 100%”
Dù vậy, nếu bạn quan tâm chủ đề này thì vẫn có nhiều dự án phát triển OS để xem
Bảo mật là một cuộc đua không có hồi kết
Trong khi đó, đã là năm 2026 mà website cá nhân của Greg vẫn chưa hỗ trợ TLS
Cấu hình bằng Caddy thì dễ, nhưng với một site tĩnh như blog cá nhân thì lợi ích thực tế của mã hóa gần như không đáng kể
Dù sao thì domain và IP vẫn bị lộ ở dạng văn bản thường, nên khác biệt cũng không nhiều
Nếu họ thực sự nghĩ vậy thì chẳng phải nên loại bỏ CNA sao?
Nhưng một số nhà nghiên cứu lại có xu hướng chỉ muốn tăng số lượng CVE, nên tìm cách gán mức ưu tiên cao cho cả những lỗi thực tế vô hại
“Nếu việc báo cáo vấn đề bảo mật bắt buộc phải dùng mã hóa, thì nên xem lại chính sách này (ý đang nói đến chính phủ Anh)”
Đoạn này đúng là buồn cười
Câu “bug chỉ là bug” là cách nói quá đơn giản
DoS cần quyền root và chiếm quyền hệ thống từ người dùng không đặc quyền là hai chuyện hoàn toàn khác nhau
Có những lỗi rõ ràng gây ra vi phạm ranh giới bảo mật, và những lỗi đó nên được phân loại là lỗi bảo mật
Đây là điều đã được giải thích với Greg suốt hàng chục năm
Kết luận là nếu không chạy phiên bản mới nhất thì kernel vẫn ở trạng thái chưa được vá hoàn toàn
CVE thì bị né tránh, còn bản vá lỗ hổng lại bị giấu trong commit log, và kẻ tấn công nhìn vào đó là nhận ra
Tôi không hiểu vì sao phải đặc biệt nhấn mạnh điều này
Khách hàng yêu cầu các bản vá liên quan đến kernel trong Docker image
Trong khi Docker lại không bao gồm kernel
Cần có cách phân phối image mà không có kernel
Các base image thông thường không bao gồm kernel