Hiểu Luật Linus về bảo mật của nguồn mở

Understanding Linus's Law for open source security

Linus'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-security

Bài được đưa lên Internet ngày: 09/02/2021

Trong 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 Linus

Thự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.

In 2021, there are more reasons why people love Linux than ever before. In this series, I'll share 21 different reasons to use Linux. This article discusses Linux's influence on the security of open source software.

An often-praised virtue of open source software is that its code can be reviewed (or "audited," as security professionals like to say) by anyone and everyone. However, if you actually ask many open source users when the last time they reviewed code was, you might get answers ranging from a blank stare to an embarrassed murmur. And besides, there are some really big open source applications out there, so it can be difficult to review every single line of code effectively.

Extrapolating from these slightly uncomfortable truths, you have to wonder: When nobody looks at the code, does it really matter whether it's open or not?

Should you trust open source?

We tend to make a trite assumption in hobbyist computing that open source is "more secure" than anything else. We don't often talk about what that means, what the basis of comparison is ("more" secure than what?), or how the conclusion has even been reached. It's a dangerous statement to make because it implies that as long as you call something open source, it automatically and magically inherits enhanced security. That's not what open source is about, and in fact, it's what open source security is very much against.

You should never assume an application is secure unless you have personally audited and understood its code. Once you have done this, you can assign ultimate trust to that application. Ultimate trust isn't a thing you do on a computer; it's something you do in your own mind: You trust software because you choose to believe that it is secure, at least until someone finds a way to exploit that software.

You're the only person who can place ultimate trust in that code, so every user who wants that luxury must audit the code for themselves. Taking someone else's word for it doesn't count!

So until you have audited and understood a codebase for yourself, the maximum trust level you can give to an application is a spectrum ranging from approximately, not trustworthy at all to pretty trustworthy. There's no cheat sheet for this. It's a personal choice you must make for yourself. If you've heard from people you strongly trust that an application is secure, then you might trust that software more than you trust something for which you've gotten no trusted recommendations.

Because you cannot audit proprietary (non-open source) code, you can never assign it ultimate trust.

Linus's Law

The reality is, not everyone is a programmer, and not everyone who is a programmer has the time to dedicate to reviewing hundreds and hundreds of lines of code. So if you're not going to audit code yourself, then you must choose to trust (to some degree) the people who do audit code.

So exactly who does audit code, anyway?

Linus's Law asserts that given enough eyeballs, all bugs are shallow, but we don't really know how many eyeballs are "enough." However, don't underestimate the number. Software is very often reviewed by more people than you might imagine. The original developer or developers obviously know the code that they've written. However, open source is often a group effort, so the longer code is open, the more software developers end up seeing it. A developer must review major portions of a project's code because they must learn a codebase to write new features for it.

Open source packagers also get involved with many projects in order to make them available to a Linux distribution. Sometimes an application can be packaged with almost no familiarity with the code, but often a packager gets familiar with a project's code, both because they don't want to sign off on software they don't trust and because they may have to make modifications to get it to compile correctly. Bug reporters and triagers also sometimes get familiar with a codebase as they try to solve anomalies ranging from quirks to major crashes. Of course, some bug reporters inadvertently reveal code vulnerabilities not by reviewing it themselves but by bringing attention to something that obviously doesn't work as intended. Sysadmins frequently get intimately familiar with the code of an important software their users rely upon. Finally, there are security researchers who dig into code exclusively to uncover potential exploits.

Trust and transparency

Some people assume that because major software is composed of hundreds of thousands of lines of code, it's basically impossible to audit. Don't be fooled by how much code it takes to make an application run. You don't actually have to read millions of lines. Code is highly structured, and exploitable flaws are rarely just a single line hidden among the millions of lines; there are usually whole functions involved.

There are exceptions, of course. Sometimes a serious vulnerability is enabled with just one system call or by linking to one flawed library. Luckily, those kinds of errors are relatively easy to notice, thanks to the active role of security researchers and vulnerability databases.

Some people point to bug trackers, such as the Common Vulnerabilities and Exposures (CVE) website, and deduce that it's actually as plain as day that open source isn't secure. After all, hundreds of security risks are filed against lots of open source projects, out in the open for everyone to see. Don't let that fool you, though. Just because you don't get to see the flaws in closed software doesn't mean those flaws don't exist. In fact, we know that they do because exploits are filed against them, too. The difference is that all exploits against open source applications are available for developers (and users) to see so those flaws can be mitigated. That's part of the system that boosts trust in open source, and it's wholly missing from proprietary software.

There may never be "enough" eyeballs on any code, but the stronger and more diverse the community around the code, the better chance there is to uncover and fix weaknesses.

Trust and people

In open source, the probability that many developers, each working on the same project, have noticed something not secure but have all remained equally silent about that flaw is considered to be low because humans rarely mutually agree to conspire in this way. We've seen how disjointed human behavior can be recently with COVID-19 mitigation:

• We've all identified a flaw (a virus).

• We know how to prevent it from spreading (stay home).

• Yet the virus continues to spread because one or more people deviate from the mitigation plan.

The same is true for bugs in software. If there's a flaw, someone noticing it will bring it to light (provided, of course, that someone sees it).

However, with proprietary software, there can be a high probability that many developers working on a project may notice something not secure but remain equally silent because the proprietary model relies on paychecks. If a developer speaks out against a flaw, then that developer may at best hurt the software's reputation, thereby decreasing sales, or at worst, may be fired from their job. Developers being paid to work on software in secret do not tend to talk about its flaws. If you've ever worked as a developer, you've probably signed an NDA, and you've been lectured on the importance of trade secrets, and so on. Proprietary software encourages, and more often enforces, silence even in the face of serious flaws.

Trust and software

Don't trust software you haven't audited.

If you must trust software you haven't audited, then choose to trust code that's exposed to many developers who independently are likely to speak up about a vulnerability.

Open source isn't inherently more secure than proprietary software, but the systems in place to fix it are far better planned, implemented, and staffed.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com