it-swarm-vi.com

Nguồn mở so với hệ thống nguồn đóng

Hiểu biết của tôi là hệ thống nguồn mở thường được cho là an toàn hơn hệ thống nguồn đóng .

Các lý do để thực hiện một trong hai cách tiếp cận hoặc kết hợp chúng, bao gồm: các chuẩn mực văn hóa, tài chính, định vị pháp lý, an ninh quốc gia, v.v. - tất cả đều liên quan đến quan điểm của văn hóa về tác động của việc mở hệ thống hoặc nguồn đóng.

Một trong những mối quan tâm cốt lõi là bảo mật. Một vị trí phổ biến chống lại các hệ thống nguồn mở là kẻ tấn công có thể khai thác điểm yếu trong hệ thống nếu biết. Một quan điểm chung chống lại các hệ thống nguồn đóng là sự thiếu nhận thức tốt nhất là một biện pháp bảo mật yếu; thường được gọi là bảo mật thông qua che khuất .

Câu hỏi là, các hệ thống nguồn mở trung bình tốt hơn cho bảo mật hơn các hệ thống nguồn đóng? Nếu có thể, vui lòng trích dẫn phân tích trong càng nhiều ngành càng tốt, ví dụ: phần mềm , quân sự , thị trường tài chính , v.v.

Câu hỏi này là Câu hỏi bảo mật CNTT trong tuần .
[.__.] Đọc ngày 25 tháng 5 năm 2012 mục blog để biết thêm chi tiết hoặc gửi câu hỏi của riêng bạn Câu hỏi trong tuần.

53
blunders

Quan niệm rằng phần mềm nguồn mở vốn đã an toàn hơn phần mềm nguồn đóng - hoặc khái niệm ngược lại - là vô nghĩa. Và khi mọi người nói điều gì đó như thế nó thường chỉ là FUD và không có ý nghĩa thúc đẩy cuộc thảo luận.

Để lý do về điều này , bạn phải giới hạn cuộc thảo luận ở a cụ thể dự án. Một phần mềm giúp gãi ngứa cụ thể, được tạo bởi một nhóm được chỉ định và có đối tượng mục tiêu được xác định rõ. Đối với một trường hợp cụ thể như vậy, có thể suy luận về việc nguồn mở hay nguồn đóng sẽ phục vụ dự án tốt nhất.

Vấn đề với tất cả các triển khai "nguồn mở" so với tất cả các triển khai "nguồn đóng" là người ta không chỉ so sánh các giấy phép. Trong thực tế, nguồn mở là ủng hộ bởi những nỗ lực tình nguyện, và nguồn đóng là phổ biến nhất trong các nỗ lực thương mại. Vì vậy, chúng tôi đang thực sự so sánh:

  • Giấy phép.
  • Truy cập mã nguồn.
  • Rất khác biệt cấu trúc khuyến khích , vì lợi nhuận so với cho vui.
  • Tình huống trách nhiệm pháp lý rất khác nhau.
  • Khác nhau, và rất khác nhau, kích cỡ nhóm và kỹ năng nhóm.
  • vân vân.

Để cố gắng đánh giá làm thế nào tất cả những điều này hoạt động để bảo mật trên tất cả các phần mềm được phát hành khi nguồn mở/đóng chỉ bị hỏng. Nó trở thành một tuyên bố ý kiến, không thực tế.

50
Jesper M

Duy trì phần mềm bảo mật hơn phần mềm không. Tất nhiên, nỗ lực bảo trì liên quan đến sự phức tạp của phần mềm đã nói và số lượng (và kỹ năng) của những người đang xem xét nó. Lý thuyết đằng sau các hệ thống mã nguồn mở an toàn hơn là có "nhiều con mắt" nhìn vào mã nguồn. Nhưng điều này phụ thuộc khá nhiều vào sự phổ biến của hệ thống.

Chẳng hạn, năm 2008 đã được phát hiện trong OpenSSL một số lỗi tràn bộ đệm , một số trong đó dẫn đến thực thi mã từ xa. Những lỗi này đã nằm trong mã trong vài năm. Vì vậy, mặc dù OpenSSL là openource có một cơ sở người dùng đáng kể (cuối cùng, thư viện SSL chính được sử dụng cho các trang web HTTPS), số lượng và sự khéo léo của kiểm toán viên mã nguồn là không đủ để vượt qua độ phức tạp vốn có của giải mã ASN.1 (một phần của OpenSSL nơi các lỗi ẩn giấu) và của mã nguồn OpenSSL (khá thẳng thắn, đây không phải là mã nguồn C dễ đọc nhất từ ​​trước đến nay).

Các hệ thống nguồn đóng có, trung bình, ít người hơn để hỏi và đáp. Tuy nhiên, nhiều hệ thống nguồn đóng có trả tiền nhà phát triển và người thử nghiệm, những người có thể cam kết thực hiện công việc toàn thời gian. Điều này không thực sự cố hữu cho câu hỏi mở/đóng; một số công ty thuê người để phát triển các hệ thống mã nguồn mở và, có thể hình dung, người ta có thể sản xuất một phần mềm nguồn đóng miễn phí (điều này tương đối phổ biến trong trường hợp "phần mềm miễn phí" cho Windows). Tuy nhiên, vẫn còn một mối tương quan mạnh mẽ giữa việc có người kiểm tra được trả tiền và là nguồn đóng (tương quan không ngụ ý nhân quả, nhưng điều này không có nghĩa là nên bỏ qua mối tương quan).

Mặt khác, việc đóng nguồn giúp che giấu các vấn đề bảo mật dễ dàng hơn, đó là xấu, tất nhiên.

Có ví dụ về cả hệ thống nguồn mở và đóng, với nhiều hoặc rất ít vấn đề bảo mật. Các hệ điều hành BSD mã nguồn mở ( FreeBSD , NetBSDOpenBSD và một vài hệ thống khác) có hồ sơ theo dõi rất tốt liên quan đến bảo mật. Solaris cũng vậy, ngay cả khi nó là một hệ điều hành nguồn đóng. Mặt khác, Windows đã (có) một danh tiếng khủng khiếp trong vấn đề đó.

Tóm tắt: theo ý kiến ​​của tôi, ý tưởng "openource ngụ ý bảo mật" được đánh giá cao. Điều quan trọng là thời gian (và kỹ năng) dành cho việc theo dõi và khắc phục các vấn đề bảo mật và điều này chủ yếu là trực giao cho câu hỏi về tính mở của nguồn. Tuy nhiên, bạn không chỉ muốn có một hệ thống an toàn, bạn còn muốn một hệ thống mà bạn tích cực biết để được bảo mật (không bị đánh cắp là quan trọng, nhưng có thể cũng ngủ vào ban đêm). Đối với vai trò đó, các hệ thống mã nguồn mở có một lợi thế nhỏ: dễ dàng bị thuyết phục rằng không có lỗ hổng bảo mật được cố tình che giấu khi hệ thống được mở. Nhưng niềm tin là một điều đáng tiếc, như đã được chứng minh với bi kịch gần đây xung quanh được cho là backreen trong OpenBSD (theo như tôi biết, hóa ra là cá trích đỏ, nhưng, về mặt khái niệm, tôi không thể chắc chắn trừ khi tôi tự kiểm tra mã).

37
Thomas Pornin

Tôi nghĩ rằng đơn giản nhất, đơn giản nhất về việc này là một kỹ thuật phần mềm. Đối số thường theo sau: phần mềm nguồn mở an toàn hơn vì bạn có thể xem nguồn !

Bạn có kiến ​​thức kỹ thuật phần mềm để hiểu hạt nhân từ trên xuống không? Chắc chắn, bạn có thể nhìn vào một trình điều khiển như vậy, nhưng bạn có kiến ​​thức đầy đủ về những gì đang xảy ra để thực sự nói "ah vâng, phải có một lỗi ở đó"?

Đây là một ví dụ thú vị: cách đây không lâu, một lỗi vô hiệu hóa con trỏ null xuất hiện trong một trong các nhân beta là một điều khá lớn, được phát hiện bởi anh chàng từ grsecurance (bản vá PaX):

Nó được giới thiệu trong một đoạn mã như thế này:

pointer = struct->otherptr;

if ( pointer == NULL )
{
    /* error handling */
}

/* code continues, dereferencing that pointer
   which with the check optimised out, can be NULL. Problem. */

pointer == NULL kiểm tra đã được tối ưu hóa bởi trình biên dịch, đúng - vì một con trỏ null không thể được quy định thành một cấu trúc có chứa các thành viên, điều đó không có nghĩa gì cho con trỏ trong hàm là null. Trình biên dịch sau đó loại bỏ kiểm tra mà nhà phát triển dự kiến ​​sẽ ở đó.

Ergo, một vis, đồng thời, mã nguồn cho một dự án lớn như vậy có thể có vẻ đúng - nhưng thực tế thì không.

Vấn đề là mức độ kiến ​​thức cần thiết ở đây. Bạn không chỉ cần phải tương đối với (trong trường hợp này) C, hội, hệ thống con hạt nhân cụ thể, mọi thứ đi cùng với việc phát triển hạt nhân mà bạn cũng cần hiểu trình biên dịch của bạn đang làm gì.

Đừng hiểu lầm tôi, tôi đồng ý với Linus rằng với đôi mắt đủ, tất cả các lỗi đều nông cạn. Vấn đề là kiến ​​thức trong não đằng sau đôi mắt. Nếu bạn trả 30 trẻ em để phát triển sản phẩm của bạn nhưng dự án nguồn mở của bạn chỉ có 5 người có kiến ​​thức thực sự về cơ sở mã, thì rõ ràng phiên bản nguồn đóng có khả năng ít lỗi hơn, giả sử độ phức tạp tương đối giống nhau .

Rõ ràng, điều này cũng dành cho bất kỳ dự án nhất định nào theo thời gian, như Thomas Pornin thảo luận.

Cập nhật được chỉnh sửa để xóa tham chiếu đến gcc bị sai, vì không phải vậy.

17
user2213

Tôi nghĩ rằng các tiền đề mà hầu hết sử dụng để phân biệt giữa nguồn đóng và nguồn mở được xác định khá rõ. Nhiều người trong số những người được liệt kê ở đây, cả hai đều có những người ủng hộ của họ. Không có gì đáng ngạc nhiên khi những người đề xuất cho Nguồn đóng là những người bán nó. Những người đề xuất cho Nguồn mở cũng đã biến nó thành một doanh nghiệp tốt đẹp và gọn gàng (ngoài một số ít người đã coi nó như một tôn giáo.)

Phong trào Nguồn mở Pro nói lên những điều cơ bản và khi nói về bảo mật nói chung, đây là những điểm phù hợp nhất trong cuộc thảo luận:

  1. Tiền đề tùy biến
  2. Tiền đề quản lý giấy phép
  3. Tiền đề định dạng mở
  4. Tiền đề nhiều mắt
  5. Tiền đề sửa chữa nhanh

Vì vậy, phá vỡ điều này bằng tiền đề, tôi nghĩ rằng hai người cuối cùng đã được những người khác ở đây che đậy khá ngắn gọn, vì vậy tôi sẽ để họ một mình.

  1. Tiền đề tùy biến
    Vì nó áp dụng cho bảo mật, Tiền đề tùy chỉnh cung cấp cho các công ty áp dụng phần mềm khả năng xây dựng các điều khiển bảo mật bổ sung trên nền tảng hiện có mà không cần phải bảo vệ giấy phép hoặc thuyết phục một nhà cung cấp sửa chữa một cái gì đó của họ. Nó trao quyền cho các tổ chức cần, hoặc nhìn thấy một khoảng trống, để tăng tính bảo mật tổng thể của sản phẩm. SELinux là một ví dụ hoàn hảo, bạn có thể cảm ơn NSA vì đã trả lại cho cộng đồng.

  2. Tiền đề quản lý giấy phép
    [.___ Hệ sinh thái nguồn. Nhưng nhiều giấy phép (đáng chú ý là GPL) áp đặt các yêu cầu đối với các nhà phân phối và hầu hết các môi trường trong thế giới thực là sự pha trộn không đồng nhất của các công nghệ nguồn đóng và nguồn mở. Vì vậy, mặc dù cuối cùng đã cắt giảm chi tiêu phần mềm, sự sẵn có của nguồn có thể khiến một số công ty vi phạm giấy phép OSS bằng cách giữ nguồn riêng tư khi họ có nghĩa vụ phát hành nguồn. Điều này cuối cùng có thể biến tiền đề quản lý giấy phép thành trách nhiệm pháp lý (là đối số nguồn đóng đối với các giấy phép như GPL.)

  3. Tiền đề định dạng mở
    [.__.] Đây là một vấn đề lớn và tôi có xu hướng đồng ý vì vậy tôi sẽ giữ nó ngắn gọn để không bị rao giảng. 30 năm kể từ bây giờ tôi muốn có thể mở một tập tin tôi đã viết. Nếu tệp được "bảo vệ" bằng các điều khiển DRM độc quyền và phần mềm tôi cần truy cập thì nó không còn được bán nữa, khó khăn trong việc truy cập nội dung của riêng tôi tăng đáng kể. Nếu có một định dạng được sử dụng để tạo tài liệu của tôi là mở và có sẵn trong một sản phẩm nguồn mở từ 30 năm trước, tôi có khả năng có thể tìm thấy nó và có thể sử dụng nó một cách hợp pháp. Một số công ty đang nhảy vào đoàn xe "Định dạng mở" mà không nhảy vào nhóm nhạc nguồn mở, vì vậy lập luận này tôi nghĩ là một âm thanh khá hay.

Có một Thứ sáu tiền đề mà tôi không liệt kê, vì nó không được thảo luận kỹ. Tôi có xu hướng bị mắc kẹt trên nó (gọi nó là hoang tưởng.) Tôi nghĩ tiền đề thứ sáu là lông vũ trong mũ của các bộ quốc phòng trên toàn thế giới. Nó được đánh vần ra thế giới khi một phần của nguồn windows 2000 bị rò rỉ.

Tiền đề trách nhiệm nguồn đóng
[.___.] Nếu một công ty đã sản xuất thư viện mã nguồn đóng hoặc API thông qua nhiều bản phát hành trong nhiều thập kỷ, các nhóm nhỏ đã có quyền truy cập vào nguồn đó trong suốt quá trình sản xuất. Một số trong số này là các nhóm kiểm toán bên thứ ba và các nhà phát triển đã chuyển sang các công ty/chính phủ khác. Nếu mã đó đủ tĩnh, để duy trì khả năng tương thích như là tiền đề lợi ích nguồn đóng, do đó một số điểm yếu có thể không được báo trước trong nhiều năm. Những người có quyền truy cập vào nguồn đóng đó có quyền tự do chạy các công cụ phân tích mã để nghiên cứu những điểm yếu này, kho lưu trữ lỗi của các cửa hàng phát triển phần mềm này chứa đầy các lỗi "nhỏ" có thể dẫn đến khai thác. Tất cả các thông tin này có sẵn cho nhiều cá nhân nội bộ.

Những kẻ tấn công biết điều này, và muốn thông tin này cho chính họ. Điều này đặt mục tiêu khổng lồ vào cơ sở hạ tầng nội bộ của công ty bạn nếu bạn là một trong những cửa hàng này. Và như nó đứng, quá trình phát triển của bạn trở thành một trách nhiệm bảo mật. Nếu công ty của bạn đủ lớn và codebase của bạn phân phối đủ tốt, bạn thậm chí có thể là mục tiêu cho các nỗ lực xâm nhập của con người. Tại thời điểm này, kỹ thuật Charlie Miller: mua chuộc một nhà phát triển có đủ tiền và anh ta sẽ viết cho bạn một lỗi không thể phát hiện trở thành một khả năng khác biệt.

Điều đó không có nghĩa là nó cũng không được đưa vào các sản phẩm OSS theo cùng một cách. Nó chỉ có nghĩa là bạn có một bộ dữ liệu, sau đó khi được phát hành, có thể phơi bày những điểm yếu trong cơ sở cài đặt của bạn. Giữ riêng tư đã tạo ra một khoản nợ mã hóa đối với các khách hàng của bạn đã cài đặt các hệ thống mà bạn không thể trả lại ngay lập tức.

13
Ori

Bạn sẽ muốn xem các giấy tờ này:

Kết quả cuối cùng là mở hoặc đóng là tương đương tùy thuộc vào số lượng thử nghiệm được thực hiện trên chúng. Và bằng cách "thử nghiệm", tôi không có nghĩa là "người thử nghiệm" máy bay không người lái trung bình của bạn làm gì, mà giống như trong trải nghiệm thực địa.

3
Bruce Ediger

Hãy trung thực ở đây, khi ai đó tuyên bố nguồn mở an toàn hơn nguồn đóng, họ đang khái quát về những gì xảy ra ngày nay trong các hệ điều hành máy chủ/máy tính để bàn, chẳng hạn như Linux (nguồn mở) so với Mac/Windows (nguồn đóng, độc quyền).

Tại sao phần mềm độc hại có nhiều khả năng ảnh hưởng đến cái sau mà không phải cái trước? Vì nhiều lý do, mà tôi nghĩ quan trọng nhất là lý do đầu tiên (mượn từ câu trả lời khác này cho một câu hỏi được đánh dấu là trùng lặp với câu hỏi này ):

  1. Phần mềm được người dùng cài đặt trong trường hợp phân phối Linux (hoặc hệ điều hành nguồn mở khác), thường được đóng gói bởi một tổ chức tập trung (tức là trong trường hợp của Ubuntu, được Canonical thực hiện và được lưu trữ bởi nó), nơi lưu trữ các tệp nhị phân được biên dịch từ các nguồn được quản lý/giám sát bởi cộng đồng nguồn mở. Điều đó có nghĩa là khả năng người dùng cài đặt phần mềm bị nhiễm hoặc khả năng cộng đồng mã nguồn mở chấp nhận thay đổi mã độc, thấp hơn nhiều so với trường hợp của Mac/Windows, nơi người dùng thường cài đặt phần mềm từ nhiều nơi khác nhau trên web hoặc từ nhiều nhà cung cấp khác nhau từ AppStores. Cũng có nguy cơ máy chủ của tổ chức (ví dụ: Canonical) bị hack, nhưng rủi ro này là nhỏ vì tổ chức này sử dụng các chuyên gia CNTT hàng đầu để chạy máy chủ của họ.
  2. Số lượng người dùng Linux (hoặc các hệ điều hành mở khác) thấp hơn nhiều so với người dùng Windows/Mac , do đó, người tạo phần mềm độc hại không muốn nhắm mục tiêu cho họ (vì lợi ích/tỷ lệ chi phí thấp hơn trong trường hợp này).
  3. Linux, chỉ là một hạt nhân, có nhiều bản phân phối khác nhau mà bạn có thể chọn , do đó, người tạo phần mềm độc hại sẽ cần phải nỗ lực nhiều hơn để tạo mã độc tương thích với nhiều người trong số họ (vì vậy tỷ lệ lợi ích/chi phí thấp hơn trong trường hợp này).
  4. Các nguồn của Linux (hoặc các hệ điều hành nguồn mở khác) được mở cho mọi người xem/sửa đổi. Điều đó có nghĩa là khi tìm thấy lỗ hổng bảo mật, bất kỳ ai cũng có thể viết một bản sửa lỗi cho nó (không có nhà cung cấp khóa, bạn không bị ràng buộc với một tổ chức cụ thể mà bạn cần chờ đợi, để phát triển một bản sửa lỗi), theo lý thuyết bản vá bảo mật xảy ra sớm hơn trong các trường hợp phần mềm độc quyền. (Tuy nhiên, trên thực tế, thường không có sự khác biệt, bởi vì các công ty điều hành các nền tảng độc quyền như Windows và MacOS, là những tập đoàn lớn có đủ năng lực.)
0
knocte

Bài viết OpenSource.com của Jim Fruchterman " Phần mềm bảo mật nguồn mở của bạn có kém an toàn hơn không? " cung cấp một sự tương tự rất tốt về cách thức nguồn mở, mặc dù những kẻ tấn công biết cách hoạt động, làm cho phần mềm an toàn hơn cho người dùng cuối :

Hãy nghĩ về mã hóa như một sự kết hợp khóa an toàn cho dữ liệu của bạn. Bạn có thể là người duy nhất có sự kết hợp hoặc bạn có thể ủy thác nó để chọn một vài cộng sự thân thiết. Mục tiêu của an toàn là giữ cho những người không được phép truy cập vào nội dung của nó. Họ có thể là những kẻ trộm cắp cố gắng đánh cắp thông tin kinh doanh có giá trị, nhân viên cố gắng tìm hiểu thông tin lương bí mật về đồng nghiệp của họ hoặc một kẻ lừa đảo muốn lấy thông tin bí mật để tiếp tục lừa đảo. Trong mọi trường hợp, bạn muốn an toàn để giữ an toàn cho công cụ của bạn và tránh xa những người không được ủy quyền.

Bây giờ hãy nói rằng tôi đang chọn một cách an toàn cho các vật có giá trị của tôi. Tôi có chọn Safe Number One được quảng cáo là có tường thép nửa inch, cửa dày inch, sáu bu lông khóa và được kiểm tra bởi một cơ quan độc lập để xác nhận rằng nội dung sẽ tồn tại trong hai giờ trong một vụ cháy? Hoặc, tôi chọn An toàn số hai, một nhà cung cấp an toàn chỉ đơn giản nói là tin tưởng, bởi vì các chi tiết thiết kế của két là một bí mật thương mại? Nó có thể là Safe Number Two được làm từ gỗ dán và kim loại tấm mỏng. Hoặc, có thể là nó mạnh hơn Safe Number One, nhưng vấn đề là tôi không biết.

Hãy tưởng tượng bạn có các kế hoạch chi tiết và thông số kỹ thuật của Safe Number One, đủ để xây dựng một bản sao chính xác của an toàn đó nếu bạn có đúng vật liệu và công cụ. Điều đó làm cho Safe Number One kém an toàn hơn? Không nó không. Tính bảo mật của Safe Number One dựa trên hai sự bảo vệ: sức mạnh của thiết kế và khó đoán được sự kết hợp của tôi. Có các kế hoạch chi tiết giúp tôi, hoặc các chuyên gia an toàn, xác định thiết kế tốt như thế nào. Nó giúp xác định rằng két an toàn không có lỗi thiết kế hoặc kết hợp "cửa sau" thứ hai ngoài sự kết hợp mà tôi chọn để mở két. Hãy nhớ rằng một thiết kế an toàn tốt cho phép người dùng chọn sự kết hợp của riêng họ một cách ngẫu nhiên. Việc biết thiết kế hoàn toàn không nên giúp kẻ tấn công đoán được sự kết hợp ngẫu nhiên của một loại an toàn cụ thể sử dụng thiết kế đó.

0
Geremia