Understanding Linus's Law for open source securityLinus's Law is that given enough eyeballs, all bugs are shallow. How does this apply to open source software security?Luật Linus là nhiều con mắt soi vào, thì lỗi sẽ cạn. Điều này áp dụng cho bảo mật của phần mềm nguồn mở như thế nào?09 Feb 2021 Seth Kenlon (Red Hat)Theo: https://opensource.com/article/21/2/open-source-securityBài được đưa lên Internet ngày: 09/02/2021Trong năm 2021, có nhiều lý do hơn vì sao mọi người yêu Linux hơn bao giờ hết so với trước đó. Trong loạt bài này, tôi sẽ chia sẻ 21 lý do khác nhau để sử dụng Linux. Bài này thảo luận ảnh hưởng của Linux lên bảo mật của phần mềm nguồn mở.Đức hạnh thường được khen ngợi của phần mềm nguồn mở là mã nguồn của nó có thể được rà soát lại (hoặc “được kiểm tra”, như những chuyên gia bảo mật thích nói) bởi bất kỳ ai và tất cả mọi người. Tuy nhiên, nếu bạn thực sự hỏi nhiều người sử dụng nguồn mở khi lần cuối họ đã rà soát lại mã nguồn là khi nào, bạn có lẽ có được câu trả lời từ cái nhìn trống rỗng cho tới lời thì thầm xấu hổ. Và ngoài ra, có vài ứng dụng nguồn mở thực sự lớn ngoài đó, nên có thể là khó để rà soát lại hiệu quả từng dòng mã nguồn.Việc ngoại suy từ sự thật khá là bất tiện đó, bạn có nghi ngờ: Khi không có ai xem mã nguồn, liệu có là đúng dù nó là mở hay không?Bạn nên tin tưởng nguồn mở?Chúng ta có xu hướng đưa ra một giả định sáo mòn trong lĩnh vực máy tính theo sở thích rằng mã nguồn mở "bảo mật" hơn bất cứ thứ gì khác. Chúng ta thường không nói nó ngụ ý gì, đâu là cơ sở của sự so sánh (“bảo mật” hơn so với cái gì?), hoặc kết luận đó đã đạt được như thế nào. Đó là một tuyên bố nguy hiểm vì nó ngụ ý miễn là bạn gọi thứ gì đó là nguồn mở, nó tự động và diệu kỳ thừa hưởng bảo mật được cải thiện. Đó không phải là những gì về nguồn mở, và trên thực tế, đó là những gì mà bảo mật nguồn mở đang chống lại rất nhiều.Bạn nên không bao giờ giả thiết một ứng dụng là bảo mật trừ phi cá nhân bạn đã kiểm tra và hiểu mã nguồn của nó. Một khi bạn đã làm điều này, bạn có thể chỉ định niềm tin tối thượng cho ứng dụng đó. Niềm tin tối thượng không là điều bạn làm trên máy tính; nó là thứ gì đó bạn làm trong tâm trí của riêng bạn: Bạn tin tưởng phần mềm vì bạn chọn tin tưởng rằng nó là bảo mật, ít nhất cho tới khi thấy một cách để khai thác phần mềm đó.Bạn chỉ là người có có thể đặt niềm tin tối thượng vào mã nguồn đó, nên bất kỳ người sử dụng nào muốn sự xa xỉ đó phải tự họ kiểm tra mã nguồn đó. Dùng lời nói của ai đó khác cho việc đó là không có giá trị!Vì thế cho tới khi bạn đã kiểm tra và hiểu kho mã nguồn đối với bản thân bạn, mức tin tưởng tối đa bạn có thể trao cho một ứng dụng là phổ có dải từ xấp xỉ, không đáng tin cậy hoàn toàn cho tới khá tin cậy. Không có sự gian lận cho việc này. Nó là sự lựa chọn cá nhân mà bạn phải tiến hành cho bản thân bạn. Nếu bạn từng nghe từ mọi người bạn tin tưởng mạnh mẽ rằng một ứng dụng là bảo mật, thì bạn có thể tin tưởng phần mềm đó hơn là tin tưởng vào một thứ gì đó mà bạn không nhận được khuyến cáo đáng tin cậy nào.Vì bạn không thể kiểm tra mã nguồn sở hữu độc quyền (không phải nguồn mở), bạn có thể không bao giò chỉ định nó là niềm tin tối thượng.Luật LinusThực tế là, không phải ai cũng là một lập trình viên, và không phải ai cũng là một lập trình viên có thời gian để chuyên tâm rà soát lại hàng trăm và hàng trăm dòng mã lệnh. Vì thế nếu bạn định tự mình kiểm tra mã nguồn, thì bạn phải chọn tin tưởng (ở vài mức độ) những ai tiến hành kiểm tra mã nguồn.Vậy chính xác ai kiểm tra mã nguồn?Luật Linus khẳng định rằng nhiều con mặt soi vào, thì lỗi sẽ cạn, nhưng chúng ta thực sự không biết có bao nhiêu con mắt là “nhiều”. Tuy nhiên, đừng đánh giá thấp số lượng. Phần mềm thường được nhiều hơn rà soát lại so với bạn có lẽ tưởng tượng. (Các) Lập trình viên gốc rõ ràng biết mã nguồn họ đã viết. Tuy nhiên, nguồn mở thường là nỗ lực của một nhóm, nên mã nguồn càng mở lâu, càng nhiều các lập trình viên dừng xem nó. Một lập trình viên phải rà soát lại các phần chính mã nguồn của một dự án vì họ phải học kho mã nguồn để viết các tính năng mới cho nó.Những người đóng gói nguồn mở cũng tham gia trong nhiều dự án để làm cho chúng sẵn sàng cho một phân phối Linux. Đôi khi một ứng dụng có thể được đóng gói với hầu hết không quen thuộc với mã nguồn đó, nhưng thường người đóng gói làm quan với mã nguồn của một dự án, vừa vì họ không muốn ký để xuất phần mềm mà họ không tin tưởng vừa vì họ có thể phải sửa đổi để làm cho nó biên dịch đúng. Những người báo cáo lỗi đôi khi cũng làm quen với kho mã nguồn khi họ cố gắng giải quyết các bất thường trải từ sự kỳ quặc tới các sự cố lớn. Tất nhiên, vài người báo cáo lỗi vô tình phát hiện các lỗi không bằng việc tự họ rà soát lại nó mà bằng việc gây chú ý về điều gì đó rõ ràng không làm việc như mong đợi. Các quản trị hệ thống thường làm quen mật thiết với mã nguồn của một phần mềm quan trọng mà những người sử dụng chúng dựa vào. Cuối cùng, có các nhà nghiên cứu bảo mật đào sâu vào mã nguồn một cách tuyệt đối để phát hiện các lỗi tiềm tàng.Tin tưởng và minh bạch Một số người giả thiết rằng vì phần mềm chính được tạo ra từ hàng trăm ngàn dòng mã lệnh, về cơ bản không thể kiểm tra nó. Đừng có rối trí vì việc có bao nhiêu mã nguồn nó có để tạo ra một ứng dụng chạy được. Bạn thực sự không phải đọc hàng triệu dòng mã lệnh. Mã lệnh có cấu trúc cao độ, và các lỗi khai thác được hiếm khi chỉ là một dòng duy nhất ẩn dấu giữa hàng triệu dòng mã lệnh; thường có toàn bộ các chức năng có liên quan.Có những ngoại lệ, tất nhiên. Đôi khi các lỗi nghiêm trọng được/bị xúc tác với chỉ một lời gọi hệ thống hoặc bằng việc liên kết tới một thư viện có lỗi. May thay, các dạng lỗi đó là khá dễ thấy, nhờ vai trò tích cực của các nhà nghiên cứu bảo mật và các cơ sở dữ liệu các lỗi.Một số người trỏ tới những người theo dõi lỗi, như website về các lỗi và lỗ hổng phổ biến - CVE (Common Vulnerabilities and Exposures), và suy ra rằng thực sự đơn giản như ban ngày rằng nguồn mở không bảo mật. Sau tất cả, hàng tram rủi ro bảo mật được đệ trình chống lại nhiều dự án nguồn mở, phơi ra công khai cho bất kỳ ai thấy. Đừng để điều đó đánh lừa bạn, dù vậy. Chỉ vì bạn không thấy các lỗi trong các phần mềm đóng không ngụ ý các lỗi đó không tồn tại. Trên thực tế, chúng ta biết rằng chúng có vì các lỗi cũng bị/được đệ trình chống lại chúng. Sự khác biệt là tất cả các lỗi chống lại các ứng dụng nguồn mở là sẵn sàng cho các lập trình viên (và người sử dụng) để thấy nên các lỗi đó có thể được giảm nhẹ. Đó là phần hệ thống mà thúc đẩy lòng tin vào nguồn mở, và điều đó hoàn toàn không có từ phần mềm sở hữu độc quyền.Có lẽ không bao giờ đủ “nhiều” các con mắt soi vào bất kỳ mã nguồn nào, nhưng cộng đồng xung quanh mã đó càng mạnh và đa dạng bao nhiêu, cơ hội phát hiện và sửa các điểm yếu càng tốt hơn bấy nhiêu.Lòng tin và con người Trong nguồn mở, xác suất mà nhiều nhà phát triển, mỗi người làm việc trong cùng một dự án, nhận thấy điều gì đó không bảo mật nhưng tất cả đều im lặng về lỗ hổng đó được coi là thấp vì con người hiếm khi đồng ý âm mưu theo cách này. Chúng ta đã thấy gần đây hành vi rời rạc của con người có thể xảy ra như thế nào để làm giảm nhẹ COVID-19: - Chúng ta tất cả đã xác định lỗi (vi rút).
- Chúng ta biết cách phòng ngừa nó để khỏi lây lan (ở nhà).
- Vâng vi rút tiếp tục lây lan vì một hoặc nhiều người hơn đi chệch khỏi kế hoạch làm giảm nhẹ.
Điều y hệt là đúng cho các lỗi trong phần mềm. Nếu có một lỗi, ai đó thấy nó sẽ mang nó ra ánh sáng (miễn là, tất nhiên, ai đó nhìn thấy nó).
Tuy nhiên, với phần mềm sở hữu độc quyền, có thể có xác xuất cao rằng nhiều lập trình viên làm việc trong một dự án có thể thấy thứ gì đó không bảo mật nhưng giữ im lặng vì mô hình sở hữu độc quyền dựa vào các tấm séc thanh toán tiền. Nếu lập trình viên nói ra chống lại một lỗi, thì lập trình viên đó có thể tốt nhất gây tổn hại tới uy tín của phần mềm đó, vì thế làm giảm doanh số bán hàng, hoặc tồi tệ nhất, có thể bị đuổi khỏi công việc của họ. Các lập trình viên đang được trả tiền để làm việc về phần mềm trong bí mật không có xu hướng để nói về các lỗi của nó. Nếu bạn từng làm việc bao giờ đó như một lập trình viên, bạn có thể đã ký một thỏa thuận không tiết lộ – NDA (Non-Disclosure Agreement), và bạn được giảng giải về tầm quan trọng của các bí mật thương mại, và hơn thế. Phần mềm sở hữu độc quyền khuyến khích, và thường thấy hơn ép tuân thủ, im lặng thậm chí khi đối mặt với các lỗi nghiêm trọng.
Lòng tin và phần mềm
Đừng tin tưởng phần mềm bạn đã chưa kiểm tra.
Nếu bạn phải tin tưởng phần mềm bạn đã không kiểm tra, thì hãy chọn tin tưởng mã nguồn được phơi ra cho nhiều lập trình viên, những người có khả năng độc lập nói ra về các lỗi.
Nguồn mở không tự nhiên bảo mật hơn so với phần mềm sở hữu độc quyền, nhưng các hệ thống có tại chỗ để sửa lỗi được lên kế hoạch, được triển khai, và được phân bổ nhân sự, tốt hơn nhiều.
Tập huấn “Chuyển đổi số - khung năng lực số và các điều kiện xây dựng nhà trường số, chương trình thực hành khai thác tài nguyên giáo dục mở” tại Cà Mau, 21-22/11/2024
‘Hướng dẫn triển khai Khuyến nghị Tài nguyên Giáo dục Mở. Lĩnh vực hành động 3: Truy cập hiệu quả, toàn diện và công bằng tới Tài nguyên Giáo dục Mở chất lượng’ - bản dịch sang tiếng Việt
‘Chương 5: Thư viện lãnh đạo việc tạo lập OER: Trường hợp điển hình của một dự án sáng thông tin cộng tác’ - bản dịch sang tiếng Việt
‘Chương 3: Sư phạm được Tài nguyên Giáo dục Mở xúc tác đáp ứng được Sáng Thông tin: Trao quyền cho các Học giả Mở thế hệ tiếp theo’ - bản dịch sang tiếng Việt
Các lớp tập huấn thực hành ‘Khai thác tài nguyên giáo dục mở’ tới hết tháng 9/2024
Hướng dẫn thực hành về Giáo dục Mở cho các học giả: Hiện đại hóa giáo dục đại học thông qua các thực hành Giáo dục Mở (dựa trên Khung OpenEdu)
Chứng chỉ Creative Commons cho các nhà giáo dục, thủ thư hàn lâm, và văn hóa mở
Các bài toàn văn & trên các tạp chí tới hết năm 2023
Các bài trình chiếu tại các hội nghị/hội thảo tới hết năm 2023
Các tài liệu dịch sang tiếng Việt tới hết năm 2023
Các mô hình bền vững Tài nguyên Giáo dục Mở (TNGDM) - Tổng hợp
ORCID - Quy trình làm việc
Tổng hợp các bài của Nhóm các Nhà cấp vốn Nghiên cứu Mở (ORFG) đã được dịch sang tiếng Việt
Tổng hợp các bài của Liên minh S (cOAlition S) đã được dịch sang tiếng Việt
Europeana - mô hình mẫu về hệ thống liên thông, Dữ liệu Mở (Liên kết) và dữ liệu FAIR của OpenGLAM/Văn hóa Mở
Năm Khoa học Mở & Chuyển đổi sang Khoa học Mở - Tổng hợp các bài liên quan
‘Bộ công cụ Khoa học Mở của UNESCO’ - Các bản dịch sang tiếng Việt
Các tài liệu chính sách và công cụ chính sách trong Loạt Nghiên cứu có Trách nhiệm của chính phủ Phần Lan đã được dịch sang tiếng Việt
Định nghĩa các khái niệm liên quan tới Khoa học Mở
‘Digcomp 2.2: Khung năng lực số cho công dân - với các ví dụ mới về kiến thức, kỹ năng và thái độ’, EC xuất bản năm 2022
‘ĐÁNH DẤU KHÓA HỌC MỞ VÀ KHAM ĐƯỢC: CÁC THỰC HÀNH TỐT NHẤT VÀ CÁC TRƯỜNG HỢP ĐIỂN HÌNH’ - VÀI THÔNG TIN HỮU ÍCH
Khóa học cơ bản về Dữ liệu Mở trong chương trình học tập điện tử trên Cổng Dữ liệu châu Âu
Các thành phần cơ bản trong kế hoạch tổng thể xây dựng chính sách tài nguyên giáo dục mở – OER (Open Educational Resources) - bản toàn văn