Cộng đồng nhân Linux đang trải qua một thời điểm... Đánh giá chuyên sâu về cách thức báo cáo và quản lý các lỗ hổng bảo mật.Điều này chủ yếu là do tác động trực tiếp của các công cụ AI lên việc kiểm tra mã nguồn. Việc áp dụng rộng rãi các hệ thống này đã làm tăng đáng kể số lượng cảnh báo bảo mật, nhưng đồng thời cũng bộc lộ một vấn đề nghiêm trọng về sự trùng lặp, nhiễu loạn và gánh nặng bổ sung cho người bảo trì.
Linus Torvalds, một nhân vật trung tâm trong dự án, thậm chí còn mô tả nó (trong Ghi chú phát hành Linux 7.1-rc4) danh sách bảo mật riêng tư của nhân hệ điều hành như “Gần như hoàn toàn không thể quản lý được” do lượng báo cáo khổng lồ được hỗ trợ bởi trí tuệ nhân tạo.Nhiều báo cáo trong số này là bản sao hoặc bị phân loại sai. Để khắc phục điều này, dự án đã phát hành tài liệu mới được tích hợp vào Linux 7.1, định nghĩa lại những gì cấu thành một lỗ hổng bảo mật thực sự và cách xử lý các báo cáo được tạo ra bằng mô hình AI.
Danh sách an ninh bị quá tải bởi các báo cáo trùng lặp.
Trong các thông báo gần đây về việc phát triển Linux 7.1, Torvalds đã cảnh báo rằng danh sách gửi thư báo cáo lỗ hổng bảo mật đã trở nên... một điểm nghẽn nơi các thông báo quan trọng bị lẫn lộn với vô số báo cáo trùng lặp.Vấn đề không chỉ nằm ở số lượng, mà là việc nhiều người khác nhau, sử dụng cùng một công cụ tự động, lại cho ra kết quả hoàn toàn giống nhau.
Như ông giải thích, các nhà phát triển lãng phí rất nhiều thời gian vào việc chuyển tiếp tin nhắn cho những người thực sự cần nhận chúng hoặc xác nhận rằng lỗi đã được khắc phục. đã được sửa lỗi vài ngày hoặc vài tuần trước trong các nhánh kernel.Tình trạng này, được một số người ví như "cơn lũ" email, buộc nguồn lực phải được dành để làm rõ các email trùng lặp thay vì tập trung vào các lỗ hổng bảo mật mới và nghiêm trọng.
Willy Tarreau, một người kỳ cựu trong việc duy trì nhân kernel ổn định, nổi tiếng với công việc của mình trên HAProxy, đã cung cấp các hình minh họa: Chỉ vài năm trước, danh sách gửi thư riêng này nhận được từ hai đến ba báo cáo mỗi tuần.Trong khi hiện nay, mỗi ngày có từ năm đến mười báo cáo được xử lý. Nhiều báo cáo trong số đó đến từ các phân tích có sự hỗ trợ của trí tuệ nhân tạo, mặc dù đôi khi chúng chỉ ra những vấn đề thực tế, nhưng lại được trình bày dưới dạng không thực tế và không cung cấp thêm thông tin liên quan.
Torvalds không chỉ trích trí tuệ nhân tạo, mà là chỉ trích việc lạm dụng nó.
Mặc dù có vẻ ngược lại, Torvalds đã nói rõ rằng Nó không phản đối việc sử dụng trí tuệ nhân tạo như một công cụ phát triển và kiểm toán.Ông ấy tự thừa nhận việc sử dụng các hệ thống này trong công việc của mình, nhưng nhấn mạnh rằng chúng phải được sử dụng một cách có trách nhiệm và thận trọng.
Trong các thông điệp gửi đến cộng đồng, ông nhấn mạnh rằng các công cụ AI “rất tuyệt vời” khi chúng thực sự hữu ích, nhưng lại trở thành vấn đề khi chúng tạo ra những thứ không cần thiết. “Nỗi đau không cần thiết và công việc giả tạo vô ích”Nói cách khác, việc một mô hình tự động chỉ ra một lỗ hổng tiềm tàng không đủ để biện minh cho việc tràn ngập các kênh an ninh bằng những báo cáo chưa được xác minh kỹ lưỡng hoặc thiếu ngữ cảnh kỹ thuật.
Torvalds khẳng định rằng bất kỳ ai sử dụng AI để tìm lỗi không nên chỉ chuyển tiếp kết quả thô, mà... Hãy đọc tài liệu về nhân hệ điều hành, hiểu rõ mô hình mối đe dọa và, nếu có thể, hãy cung cấp bản vá lỗi hoặc ít nhất là một lời giải thích rõ ràng về tác động của nó.Mục tiêu là để con người gia tăng giá trị cho công việc tự động hóa, thay vì chỉ đóng vai trò trung gian giữa công cụ và danh sách gửi thư.
Các quy tắc mới trong Linux 7.1: thế nào là lỗ hổng bảo mật và thế nào không phải.
Để giải quyết tình huống này, dự án nhân kernel đã tích hợp tài liệu chính xác hơn vào Linux 7.1 về vấn đề này. Những lỗi nào nên được coi là lỗ hổng bảo mật và những lỗi nào chỉ đơn thuần là sự cố cần được xử lý thông qua các kênh thông thường.Văn bản này, do Willy Tarreau viết, đã có sẵn trong cây Git của nhân hệ điều hành và được phát hành trước khi Linux 7.1-rc4 ra mắt.
Hướng dẫn này bắt đầu từ một ý tưởng đơn giản: Hầu hết các lỗi không nên được chuyển hướng qua danh sách bảo mật riêng tư.Thay vào đó, chúng nên được giải quyết công khai trên các danh sách gửi thư phát triển phần mềm. Thảo luận vấn đề công khai thu hút nhiều người đánh giá hơn, bao quát nhiều trường hợp sử dụng hơn và nhìn chung dẫn đến các giải pháp chất lượng cao hơn.
Tài liệu này ghi chú rằng Linux đã có sẵn một mô hình mối đe dọa được xác định rõ ràngHiện nay, điều này đóng vai trò là điểm tham chiếu chính khi quyết định xem liệu một lỗ hổng bảo mật có nên được xử lý riêng tư hay không. Lỗ hổng bảo mật được định nghĩa là lỗ hổng cho phép kẻ tấn công có được các khả năng mà một hệ thống sản xuất được cấu hình đúng cách không nên có, có thể khai thác được và gây ra mối đe dọa thực sự cho một số lượng lớn người dùng.
Trên thực tế, những người phát hiện ra vấn đề được khuyến khích tự hỏi liệu lỗi đó có phải là do lỗi đó gây ra hay không. Trong một hoàn cảnh thông thường, điều đó thực sự vượt quá giới hạn về lòng tin.Nếu câu trả lời là không, phương pháp được khuyến nghị là kiểm tra các danh sách gửi thư công khai (như LKML và các danh sách gửi thư dành riêng cho hệ thống con), chứ không phải kênh bảo mật hạn chế. Tuy nhiên, hướng dẫn vẫn cho phép một mức độ thận trọng nhất định: khi nghi ngờ, tốt hơn hết là nên xem xét riêng một báo cáo đáng ngờ hơn là để một lỗ hổng thực sự bị phát hiện.
Một điểm quan trọng khác của văn bản là: Việc gửi các lỗi thông thường đến danh sách gửi thư riêng không làm cho chúng được sửa chữa nhanh hơn.Ngược lại, nó lại tiêu tốn thời gian phân loại sự cố mà nhóm bảo mật cần để ưu tiên xử lý các lỗi thực sự nghiêm trọng. Việc làm ngập kênh đó bằng các vấn đề nhỏ cuối cùng sẽ làm suy yếu khả năng bảo vệ tổng thể của các hệ thống dựa trên Linux, bao gồm máy chủ, cơ sở hạ tầng đám mây và các thiết bị công nghiệp.
Mô hình mối đe dọa: phân tách đặc quyền và các trường hợp ngoại lệ
Tài liệu mới cập nhật và mô tả chi tiết mô hình mối đe dọa hạt nhân, liệt kê các đảm bảo mà việc vi phạm chúng được coi là vi phạm. một vấn đề an ninh cần được ưu tiên chú ýCác biện pháp này bao gồm việc tách biệt không gian người dùng và nhân hệ điều hành, cách ly bộ nhớ giữa các tiến trình, hạn chế ptrace, cách ly các cơ chế IPC và mạng, và các biện pháp bảo vệ liên quan đến các khả năng nhạy cảm như CAP_SYS_ADMIN, CAP_NET_ADMIN hoặc CAP_SYS_PTRACE.
Cần đặc biệt chú ý đến không gian tên người dùng, nơi các thiết lập như CONFIG_USER_NS cho phép người dùng không có đặc quyền tạo ra các môi trường biệt lập. Dự án kỳ vọng rằng Những trường hợp đó không thể làm tổn hại đến hệ thống toàn cầu.Do đó, bất kỳ sự vi phạm nào đối với sự cô lập đó đều có ý nghĩa về mặt an ninh.
Các giao diện gỡ lỗi như /proc/kmsg, perf hoặc debugfs cũng được phân tích, cần lưu ý rằng việc truy cập thông tin nhạy cảm thông qua các cơ chế này tiềm ẩn rủi ro. Nó phải bị chặn trừ khi được quản trị viên cho phép rõ ràng.Nếu không, sẽ có nguy cơ rò rỉ dữ liệu có thể được sử dụng để tinh chỉnh các cuộc tấn công hoặc leo thang đặc quyền.
Cùng với định nghĩa về bảo hành này, hướng dẫn cũng làm rõ loại vấn đề nào. Chúng không nên được tự động gắn nhãn là lỗ hổng bảo mật.Danh mục này bao gồm các lỗi trong các nhánh kernel lỗi thời, các tùy chọn biên dịch không an toàn do quản trị viên lựa chọn, quyền truy cập không chính xác trong sysctl hoặc hệ thống tệp, các hàm dành riêng cho việc gỡ lỗi (LOCKDEP, KASAN, FAULT_INJECTION) và mã thử nghiệm trong các khu vực dàn dựng.
Những khiếm khuyết cần Quyền hạn quá mức, các kịch bản thí nghiệm xa rời thực tế, phần cứng bị thao túng, số lượng thử nghiệm không thể kiểm soát. hoặc các cấu hình mà không một quản trị viên nào có lý trí lại áp dụng trong môi trường sản xuất. Tương tự, rò rỉ dữ liệu mà không có lỗ hổng khai thác rõ ràng và một số vấn đề trong ảnh hệ thống tập tin, thường được xử lý bởi các công cụ như fsck, nằm ngoài phạm vi cốt lõi của kênh bảo mật.
Những phát hiện được hỗ trợ bởi trí tuệ nhân tạo: từ lĩnh vực tư nhân đến lĩnh vực công cộng
Một trong những thay đổi nổi bật nhất trong bản cập nhật là cách tiếp cận đối với các lỗi được phát hiện nhờ sự hỗ trợ của trí tuệ nhân tạo. Tài liệu nêu rõ rằng: Các lỗi được phát hiện thông qua phân tích tự động về cơ bản nên được coi là lỗi công khai.ngay cả khi chuyến hàng đầu tiên được gửi bằng thư tư nhân.
Lý do hoàn toàn mang tính thực tiễn: kinh nghiệm gần đây của đội ngũ bảo mật cho thấy những sự cố này thường xuyên xảy ra. đồng thời trong tay một số nhà nghiên cứu Những người đang thử nghiệm các công cụ tương tự. Thường thì trong vòng vài giờ, nhiều email mô tả cùng một tình trạng, với một vài khác biệt nhỏ về định dạng, sẽ được gửi đến, khiến cho việc kỳ vọng giữ bí mật lâu dài trở nên không thực tế.
Thực tế mới này khiến Torvalds lập luận rằng Sẽ thật vô lý nếu coi những phát hiện này như những bí mật cần phải giấu kín cho đến khi có bản vá lỗi.Nếu một AI thông thường có thể tìm ra chúng, thì có lý do để cho rằng các tác nhân khác, bao gồm cả những kẻ tấn công tiềm năng, cũng có thể đạt được kết quả tương tự. Việc gắn nhãn chúng là các lỗ hổng bảo mật chỉ làm tăng thêm công việc và làm phức tạp thêm sự phối hợp.
Điều đó không có nghĩa là nên công bố tất cả các chi tiết kỹ thuật mà không lọc. Hướng dẫn yêu cầu rằng, trong các trường hợp được phát hiện bằng AI, Hiện chưa có bản vá lỗi nào được chia sẻ ngay lập tức. (Trình tự chính xác các bước hoặc đoạn mã gây ra lỗi). Cách tiếp cận phù hợp là chỉ ra rằng tài liệu này tồn tại và cho phép người bảo trì yêu cầu tài liệu này một cách riêng tư nếu họ thấy cần thiết để xác nhận bản sửa lỗi.
Với cách tiếp cận này, dự án cố gắng kết hợp hai lợi ích: một mặt, Tránh làm cho danh sách riêng tư trở nên lộn xộn với những phát hiện mà người khác đã biết.Mặt khác, điều quan trọng là không nên cung cấp "công thức" khai thác cho bất kỳ ai trước khi các biện pháp giảm thiểu được thực hiện. Trình phát đa phương tiện được công nhận là một công cụ có giá trị cho cả việc gỡ lỗi và đánh giá tác động, nhưng cũng là một vấn đề nhạy cảm nếu nó được phân phối mà không có các biện pháp kiểm soát tối thiểu.
Yêu cầu về chất lượng đối với báo cáo do AI tạo ra
Tài liệu hướng dẫn mới dành hẳn một phần để hướng dẫn cách viết báo cáo được hỗ trợ bởi AI. Lời phàn nàn thường xuyên từ các nhóm bảo trì là nhiều báo cáo này được gửi đến không đúng cách. Nội dung quá phóng đại, kèm theo những giải thích thừa thãi và thiếu tập trung vào dữ liệu thiết yếu.Điều này làm cho việc đọc và phân loại nó trở nên phức tạp hơn.
Trước tiên, cần yêu cầu các báo cáo phải được... Ngắn gọn, rõ ràng và bằng văn bản đơn giản.Nhóm không khuyến khích sử dụng các định dạng như Markdown, các từ ngữ hoa mỹ hoặc cấu trúc phức tạp không phù hợp với các phản hồi nối tiếp trên danh sách gửi thư. Ý tưởng là khi chuyển tiếp hoặc trích dẫn tin nhắn, không có thông tin nào bị mất và văn bản không trở thành một khối khó đọc.
Về nội dung, nên bắt đầu với... Bản tóm tắt đơn giản chỉ ra tệp hoặc hệ thống con bị ảnh hưởng, các phiên bản bị ảnh hưởng và tác động có thể quan sát được của lỗi.Từ đó, có thể bổ sung thêm chi tiết, nhưng luôn với mục đích giúp người đọc nhanh chóng xác định xem lỗi đó là vấn đề ưu tiên hay chỉ là vấn đề nhỏ.
Một khía cạnh quan trọng khác là cách mô tả tác động. Các nhà phát triển nhân hệ điều hành cảnh báo rằng nhiều báo cáo do AI tạo ra... Họ có xu hướng phóng đại các hệ quả lý thuyết.Việc xâu chuỗi các kịch bản giả định không tuân thủ mô hình mối đe dọa thực tế của dự án. Thay vì xây dựng các câu chuyện tấn công phức tạp, người tham gia được yêu cầu bám sát các sự kiện có thể kiểm chứng, chẳng hạn như giải thích cụ thể những khả năng bổ sung mà người dùng có thể có được trên một hệ thống được cấu hình tiêu chuẩn.
Hướng dẫn này thậm chí còn đề xuất rằng, nếu khả thi, chính công cụ AI nên đọc trước tài liệu về mô hình mối đe dọa của Linux. để phù hợp các kết luận của nó với các tiêu chí đã được thiết lập bởi dự án.Mục tiêu là giảm thiểu sự hiểu lầm và ngăn chặn việc báo cáo tự động biến một lỗi có tác động hạn chế thành một lỗ hổng nghiêm trọng mà không có cơ sở thực tế nào.
Người chơi, các bản vá lỗi và lẽ thường trong thời đại tự động hóa
Ngoài cách mô tả lỗi, tài liệu còn tập trung vào các khía cạnh thực tiễn hơn: Tạo và xác thực người chơi và bản vá lỗi bằng trí tuệ nhân tạoNhiều công cụ hiện đại có thể tạo ra các chương trình hoặc kịch bản kiểm thử nhỏ để kích hoạt lỗi, cũng như đề xuất các thay đổi mã để khắc phục lỗi, nhưng chúng không phải lúc nào cũng thực hiện điều đó một cách đáng tin cậy.
Nhân hệ điều hành yêu cầu rằng, trước khi gửi báo cáo, Nhà nghiên cứu phải tự mình xác minh rằng trình phát hoạt động đúng như mô tả.Nếu chuỗi thao tác không gây ra lỗi, hoặc nếu AI không thể tạo ra phương pháp có thể tái tạo, tính hợp lệ của báo cáo sẽ bị ảnh hưởng nghiêm trọng. Việc công bố kết quả mà không có sự xác minh này chỉ làm tăng thêm nhiễu và lãng phí thời gian của người bảo trì.
Về các bản vá lỗi, văn bản nhấn mạnh rằng nhiều AI thậm chí còn tốt hơn. viết mã để đánh giá tác động của nóDo đó, người dùng các công cụ này được khuyến khích không chỉ yêu cầu chúng xác định vấn đề mà còn đề xuất giải pháp. Tuy nhiên, cần nhấn mạnh rằng kết quả phải được xem xét và kiểm tra thủ công trước khi gửi đến danh sách gửi thư của bộ phận phát triển.
Hướng dẫn này rất rõ ràng trong trường hợp không thể kiểm tra bản vá vì nó phụ thuộc vào... Phần cứng độc đáo, giao thức mạng gần như tuyệt chủng hoặc cấu hình cực kỳ hiếm gặp.Nếu một lỗi chỉ xuất hiện trong một môi trường hiếm hoi đến mức không ai có thể dễ dàng xác nhận được, thì rất có thể nó không thuộc loại lỗ hổng bảo mật cần thiết và không nên chiếm thời gian của kênh thảo luận riêng.
Khi đề xuất bản vá lỗi, dự án nhắc nhở người dùng rằng bản vá phải tuân thủ các hướng dẫn gửi bản vá kernel tiêu chuẩn, bao gồm cả nhãn. “Sửa lỗi:” cho biết bản cập nhật cụ thể đã gây ra lỗi.Cũng nên áp dụng tư duy logic: nếu tập tin bị ảnh hưởng không thay đổi trong hơn một năm và chỉ do một người duy nhất quản lý, thì có thể đó là một thành phần có rất ít người dùng thực sự, chẳng hạn như trình điều khiển phần cứng cũ hoặc hệ thống tập tin lỗi thời.
Trong những trường hợp này, khuyến nghị rất rõ ràng: nếu vấn đề nhỏ nhặt, dễ phát hiện và không gây ảnh hưởng rõ rệt trong môi trường thông thường, Cách tiếp cận hợp lý nhất là giải quyết trực tiếp thông qua danh sách phát triển công cộng. và không nằm trong danh sách dành riêng cho an ninh. Bằng cách này, các nguồn lực nhạy cảm nhất được dành riêng cho các sự cố có khả năng gây hậu quả nghiêm trọng.
Từ kỷ nguyên của kỹ thuật làm mờ mã đến cơn lũ AI: những bài học cho phần mềm tự do
Tình hình hiện tại phần nào gợi nhớ đến thời kỳ khi các công cụ tạo hiệu ứng fuzzing như Syzkaller bắt đầu xuất hiện. Gửi hàng loạt báo cáo về các lỗi đã phát hiện đến nhân hệ điều hành một cách bán tự động.Vào thời điểm đó, cộng đồng phải học cách tích hợp dòng chảy liên tục của những phát hiện đó vào quá trình phát triển của mình mà không làm gián đoạn công việc hàng ngày.
Điều tương tự cũng xảy ra với trí tuệ nhân tạo, nhưng ở quy mô khác. Giờ đây, không chỉ việc tạo ra các dữ liệu đầu vào gây ra lỗi được tự động hóa, mà còn... Việc soạn thảo các báo cáo, phân tích tĩnh mã nguồn và đề xuất các bản vá lỗi.Điều này giúp tăng tốc độ tìm lỗi, nhưng nếu không được lọc và ưu tiên đúng cách, nó cũng làm tăng số lượng email, các cuộc thảo luận song song và kỳ vọng về những gì nhóm phát triển nhân hệ điều hành có thể xử lý.
Trong chính hệ sinh thái Linux, việc đánh giá hiện tượng này cũng có những sắc thái khác nhau. Greg Kroah-Hartman, một người duy trì nhân kernel quan trọng khác, đã chỉ ra rằng Các báo cáo do AI tạo ra đã nhanh chóng chuyển từ chỗ hầu như luôn là những thông tin vô nghĩa sang trở thành những đóng góp có giá trị.Quan điểm lạc quan hơn này tồn tại song song với mối lo ngại của Torvalds về sự dư thừa các bản sao và tình trạng quá tải của danh sách bảo mật.
Thay vì là một sự mâu thuẫn, những quan điểm này phản ánh hai khía cạnh của cùng một quá trình nhận con nuôiMột mặt, trí tuệ nhân tạo có thể rất hữu ích trong việc tìm ra các vấn đề thực tế; mặt khác, nếu nhiều người cùng sử dụng một công cụ trên cùng một đoạn mã và gửi kết quả mà không lọc, hiệu ứng tổng hợp sẽ tạo ra một "cơn bão" cảnh báo khó quản lý.
Một ví dụ về việc sử dụng tự động hóa một cách có trách nhiệm được chính Kroah-Hartman đưa ra, người đã công bố các hệ thống tùy chỉnh để quét nhân hệ điều hành, tạo bản vá, kiểm tra chúng và gửi chúng theo quy trình làm việc tiêu chuẩn của dự án. Điều quan trọng là, trong những trường hợp này, Nhà phát triển chịu trách nhiệm hoàn toàn về mặt kỹ thuật cho toàn bộ vòng đời dự án.Thay vì chỉ đơn thuần chuyển tiếp mà không kiểm tra kết quả đầu ra của công cụ.
Toàn bộ phong trào xoay quanh Linux 7.1 cho thấy một dự án, thay vì bác bỏ trí tuệ nhân tạo, lại đang... Điều chỉnh quy trình của họ sao cho tự động hóa có lợi cho bảo mật chứ không phải chống lại nó.Bằng cách đặt ra các tiêu chí nghiêm ngặt hơn về những gì cấu thành nên một lỗ hổng bảo mật, yêu cầu các báo cáo dạng văn bản thuần có thể kiểm chứng được và khuyến khích trí tuệ nhân tạo đóng góp vào việc tạo và kiểm thử các bản vá, nhân kernel hướng đến mục tiêu bảo vệ thời gian của người bảo trì, giảm thiểu sự nhiễu loạn thông tin và tập trung nỗ lực vào các lỗi thực sự có thể gây nguy hại cho các hệ thống đang hoạt động.