it-swarm-vi.com

Giữ bí mật từ root trên Linux

Tôi đang tìm cách để làm cứng hệ thống linux để ngay cả khi có quyền truy cập root đầy đủ (thông qua các phương tiện hợp pháp hoặc không hợp pháp), một số bí mật vẫn không thể truy cập được. Nhưng trước tiên một chút nền tảng.

Nhiều mô hình bảo mật linux khác nhau (SELinux, TOMOYO, v.v.) tập trung vào việc giới hạn các quy trình có thể làm theo chính sách và đảm bảo rằng chúng không cần quyền truy cập root đầy đủ. Họ nhằm mục đích giữ bất kỳ khai thác nào được chứa để các phần khác của hệ thống không thể bị xâm phạm. Tuy nhiên, có vẻ như những điều này không trực tiếp giải quyết trường hợp đã lấy được toàn bộ root - hoặc, thậm chí xa hơn, giữ bí mật từ người dùng root hợp lệ. Dường như những thứ này thường có thể bị tắt bởi root thực sự trong thời gian chạy.

Một cách tiếp cận khác là hạn chế các cách để có được quyền root hoàn toàn không bị hạn chế - ví dụ: không cho phép tất cả quyền truy cập vào người dùng root được kết nối từ xa, nhưng yêu cầu đăng nhập từ bảng điều khiển vật lý. Tuy nhiên, đây cũng không phải là mục tiêu của tôi - giả định là bất kỳ sự bảo vệ nào như vậy đã được khắc phục và gốc rễ là hợp pháp như nó có thể.

Rõ ràng là bất cứ ai có quyền truy cập vật lý vào máy đều có thể lấy mọi thứ được lưu trữ trên ổ cứng và cũng có thể là mọi thứ được lưu trong bộ nhớ. Rõ ràng là nếu người dùng root có quyền sửa đổi nhị phân hoặc hình ảnh kernel, thì không có lời hứa bảo mật nào có thể được đưa ra sau khi khởi động lại. Tôi chỉ quan tâm đến các cuộc tấn công có thể được thực hiện mà không cần khởi động lại hệ thống.

Ngoài ra, trong quá trình khởi động, nhiều khả năng các bí mật sẽ được truyền qua nhiều nơi và cần nhiều chức năng quan trọng về bảo mật. Thật tuyệt vời nếu bí mật cũng có thể được bảo vệ trong quá trình khởi động, nhưng điều đủ cho tôi là một bước trong quá trình khởi động nơi các đặc quyền nâng cao có thể bị loại bỏ và sau đó không có cách nào để lấy lại chúng.

Vì vậy, với những hạn chế này, các cách trên Linux để ngăn chặn người dùng root hoàn toàn truy cập một số bí mật là gì?

  • Có thể có các tệp trên hệ thống tệp không thể truy cập được ngay cả với toàn bộ root bằng bất kỳ phương tiện nào, nhưng có thể truy cập được vào một số quy trình không? Một số quy trình hiện đang chạy hoặc thậm chí các quy trình mới được bắt đầu bởi các quy trình hiện đang có quyền truy cập?

  • Có thể giữ bí mật trong bộ nhớ bằng cách chạy các quy trình để thậm chí toàn bộ root không thể truy cập được bằng bất kỳ phương tiện nào không? Những bí mật này có thể được truyền đến các quy trình mới bằng một số phương tiện mà root có thể ảnh hưởng?

Đây là một câu hỏi khó để viết để tôi có câu trả lời phù hợp với mình, vì vậy tôi sẽ cố gắng chỉnh sửa câu hỏi để cụ thể hơn nếu cần thiết.


Rõ ràng những điều đến với tâm trí cần được giới hạn sẽ là:

  • Vô hiệu hóa quyền truy cập vào/Proc/mem

  • Vô hiệu hóa quyền truy cập vào/Proc/<pid>/mem

  • Vô hiệu hóa quyền truy cập vào/Proc/<pid>/fd/*

  • Vô hiệu hóa tải mô-đun (tốt nhất là sau khi một số mô-đun đã được tải, tốt nhất là)

  • Vô hiệu hóa quyền truy cập ptrace vào bất kỳ quy trình

56
Nakedible

Trên thực tế, có thể hạn chế root if người ta chuẩn bị xác định một hạn chế đó là về cơ bản tin tưởng vào hệ điều hành. Điều này có thể được thực hiện bằng cách sử dụng SELinux (mà tôi biết) và có lẽ các hệ thống khác như vậy. Ví dụ tốt nhất mà tôi đã thấy về SELinux được sử dụng theo cách như vậy là Russell Coker's Chơi máy Selinux .

Như một tổng quan ngắn gọn về cách thức hoạt động của nó, tên "root" không phải là đặc biệt trong Unix. UID 0 là. UID 0 được hiểu là "tin tưởng tất cả những gì tôi nói". Điều này đặc biệt áp dụng cho mô hình truy cập tiêu chuẩn được sử dụng trên Unices, Unixen hoặc tuy nhiên bạn số nhiều "Unix".

LSM, hoặc Mô-đun bảo mật Linux, cho phép bạn kết nối mọi thứ và kiểm tra/từ chối các hành động khi bạn thấy phù hợp. Trong trường hợp của SELinux, các quyền của SELinux được kiểm tra sau các quyền của Unix, vì vậy luồng của bạn trông như thế này:

Event ----> Has Unix Permissions? ---> Has SELinux Permissions? ---> Let it happen

Giai đoạn tiếp theo để hiểu là có, hoặc đã từng là các phiên bản khác nhau của Chính sách SELinux. Trước khi tôi hiểu điều đó, hãy hiểu điều đó trong SELinux:

  • các nút có các loại, hậu tố _t, cũng có thể được gọi là tên miền; và
  • người dùng có vai trò, hậu tố _r.

Kết hợp lại, họ kiểm soát hành động nào mà người dùng trong một vai trò nhất định có thể làm và quy trình trong một miền nhất định có thể làm gì.

Bây giờ, có ba chính sách chính của SELinux:

  1. được nhắm mục tiêu. Đây là chính sách mặc định cho máy tính để bàn như Fedora. Ý tưởng của mục tiêu là các dịch vụ và trình nền hệ thống quan trọng được chạy trong các miền, nhưng rất nhiều thứ mà người dùng cuối thực hiện được chạy trong unconfined_u:unconfined_r:unconfined_t. Không có giải thưởng cho việc đoán điều đó có nghĩa là gì - nếu các quyền của Unix hoạt động, SELinux thực sự được thông qua.
  2. nghiêm ngặt. Chính sách này liên quan đến việc xóa unconfined_u hoàn toàn. Đây không phải là một quá trình dễ dàng, đặc biệt là trên máy tính để bàn Linux (tức là init 5). Cụ thể, mô hình bảo mật X11 không tuyệt vời và thường yêu cầu unconfined_t cho một số ứng dụng. Bạn có thể làm điều này , nhưng tôi mong muốn làm việc với X11 sẽ khó hơn (mặc dù không phải là không thể) đặc biệt là khi thực thi các ứng dụng GUI yêu cầu root. Có một dự án đang được tiến hành để cung cấp hỗ trợ cho chức năng tương tự SELinux trong X, được gọi là XACE (Tiện ích mở rộng kiểm soát truy cập X) .
  3. MLS. MLS là viết tắt của bảo mật đa cấp và có nghĩa là kết thúc chuỗi cấp phép: user_u:system_r:httpd_content_t.s0-s2:c5-c7, tức là những số sc thực sự có ý nghĩa gì đó. Cụ thể, chúng tạo thành một không đọc lên, không ghi lại thiết lập sao cho trừ khi quá trình đang chạy ở một mức nhất định, thông tin họ có thể thấy sẽ bị giới hạn. Ý tưởng của cấp độ thông tin này là để bảo vệ các tài sản được phân loại, ban đầu được tổ chức bởi NSA, có lẽ cho mục đích này.

Vì vậy, đó là nền tảng của bạn. Bây giờ, theo các trang web (xem FAQ ) root là UID 0 trên máy chơi; tuy nhiên, root được thiết lập để chạy dưới dạng user_r và không sysadm_r trong nghiêm ngặt chính sách. Điều này có nghĩa là người dùng sẽ không được phép thực thi các chức năng quản trị từ Shell.

Sau đó, điều thú vị là biết trạng thái của các quá trình khác yêu cầu root. Có lẽ các quy trình như vậy đã được dán nhãn thích hợp và có các chính sách cho phép họ truy cập mà họ yêu cầu. Câu hỏi sau đó trở thành cách bạn quản trị hệ thống và bất kỳ quy trình nào trong số này có thể khởi chạy Shell trong bối cảnh của người dùng đó. Nếu điều đó có thể xảy ra, bạn vẫn có thể quản lý khai thác.

Vì máy chơi hiện đang ngừng hoạt động (tại thời điểm viết bài), tôi đang làm việc với các giả định ở đây; nhưng về cơ bản, bạn sẽ cần một quy trình chạy trong sysadm_r và với UID 0 làm mục tiêu khai thác. Giả sử quá trình như vậy tồn tại và có thể khai thác, bạn vẫn có thể root. Đối với việc vẫn có thể quản trị thông qua root, có hai tùy chọn mà tôi có thể nghĩ đến:

  • Có một sự chuyển đổi đáng tin cậy của một số loại có nghĩa là root có thể chuyển sang sysadm_r (kém an toàn) hoặc
  • Trên các runlevels khác nhau, một chính sách khác nhau được áp dụng, vì vậy, để quản trị máy, người ta đặt runlevel thành 1 và chính sách không hạn chế root. Tôi đoán ở đây.

Tóm lược

Nếu câu hỏi của bạn là "tôi có thể dễ dàng và an toàn làm điều này bây giờ không?" câu trả lời là không. Nếu câu hỏi của bạn là "Tôi đã sẵn sàng để tìm hiểu về SELinux, hãy chán nản với bản phân phối của mình và đưa ra khá nhiều thứ không hoạt động", câu trả lời là có thể hạn chế root nhiều hơn so với cài đặt trung bình của bạn. Điều đó nói rằng, điều này không theo bất kỳ cách nào khiến bạn trở nên bất khả xâm phạm khi khai thác, nó không khiến người dùng không thể phá vỡ sự kiểm soát truy cập bổ sung này cả về phần mềm hoặc vật lý.

Vì vậy, có, bạn có thể làm cho mọi thứ vô hình để root; tuy nhiên, gánh nặng kỹ thuật thêm sang một bên, hãy cẩn thận áp dụng cho mọi thiết lập kiểm soát truy cập trên bất kỳ người dùng bình thường nào, không có viên đạn bạc.

Tự quảng cáo một cách trắng trợn: bạn có thể thích bài đăng trên blog của tôi trên lưu trữ bí mật trong phần mềm . Đó là trên blog stackexchange bảo mật, vì vậy tôi không cảm thấy quá tệ khi quảng bá điều đó. Về cơ bản, như bạn có thể thấy, có những cơ chế khiến cuộc sống của kẻ tấn công (và bạn) trở nên khó khăn hơn rất nhiều, nhưng cuối cùng, đó là một trường hợp "rùa hết cỡ", về cơ bản là không thể làm được.

33
user2213

Tôi đã phải giải quyết vấn đề này trước đây, khi được tiếp cận bởi một khách hàng muốn giữ "tin nhắn riêng tư" an toàn giữa những người dùng trên một trang web. Có thể bảo vệ một số dữ liệu trong một số trường hợp, nhưng điều này bị hạn chế một cách hợp lý.

Cách tiếp cận của tôi chỉ đơn giản là lưu trữ một phiên bản mã hóa của ghi chú trên máy chủ và gửi nó cho họ (dĩ nhiên là đã được xác thực), sau đó giải mã nó hoàn toàn ở phía máy khách. Điều này có nghĩa là ngay cả trong trường hợp thỏa hiệp hoàn toàn về bảo mật máy chủ (tức là quyền truy cập root), các ghi chú vẫn được bảo mật. Những hạn chế của điều này tuy nhiên:

  • Dữ liệu được bảo vệ chỉ được bảo mật cho đến thời điểm thỏa hiệp và không muộn hơn. Tùy thuộc vào phương thức được sử dụng để mã hóa thông tin, máy chủ đã root có thể lừa người dùng tiết lộ các khóa giải mã (JavaScript JavaScript hoặc cho các máy khách GUI gốc, phát hành bản cập nhật máy khách bị xâm nhập) hoặc chặn các khóa giải mã (nếu các khóa dựa trên tắt phương thức tương tự như xác thực người dùng, chẳng hạn như mật khẩu, họ có thể bị chặn trong quá trình xác thực phía máy chủ).
  • Truyền dẫn yêu cầu bảo mật hoàn hảo về phía trước nếu không dữ liệu được mã hóa có thể bị chặn, lưu trữ và sau đó được giải mã sau khi thỏa hiệp như đã thảo luận ở trên.
  • Điều này không bảo vệ bất cứ điều gì nếu khách hàng cũng bị xâm phạm. Trừ khi bạn xử lý dữ liệu được mã hóa hoàn toàn trong đầu của chính bạn (và nếu bạn có thể, bạn xứng đáng với một danh hiệu hoặc thứ gì đó), bạn sẽ cung cấp dữ liệu nhạy cảm cho một cái gì đó, và không có gì là - hoàn hảo không thể tha thứ.
  • Không có cách nào sử dụng phía máy chủ dữ liệu này (tức là cho mục đích lập chỉ mục) trừ khi siêu dữ liệu có thể giải mã/văn bản gốc được lưu trữ bên cạnh, có thể tiết lộ thông tin bổ sung.

Về cơ bản, điều này hạn chế việc sử dụng tiềm năng cho kịch bản này và vẫn còn những điểm yếu, nhưng nó có thể hoạt động trong một số tình huống. Băm mật khẩu là một ví dụ (hợp lý) thành công của 'bảo vệ thỏa hiệp gốc', trong đó ngay cả truy cập vật lý sẽ không tiết lộ mật khẩu của người dùng (tất nhiên trừ khi mật khẩu đó được truyền sau khi thỏa hiệp).

Có các ví dụ khác trong luồng này cũng đáng để xem xét, nhưng hãy suy nghĩ về kịch bản xử lý phía máy khách, sử dụng máy chủ đơn giản như một dịch vụ lưu trữ an toàn.

TC

14
TC Fox

Có thể có các tệp trên hệ thống tệp không thể truy cập được ngay cả với toàn bộ root bằng bất kỳ phương tiện nào, nhưng có thể truy cập được vào một số quy trình không? Một số quy trình hiện đang chạy hoặc thậm chí các quy trình mới được bắt đầu bởi các quy trình hiện đang có quyền truy cập?

Không. Khi một quá trình có thể truy cập chúng, vì vậy có thể root. Nếu bạn muốn làm những việc như vậy, bạn sẽ phải sửa đổi mạnh mẽ toàn bộ hệ thống, có thể là hệ thống khởi động hạt nhân bất biến từ một số thiết bị chỉ đọc và từ chối quyền truy cập tập tin/bộ nhớ gốc trong khi cho phép người dùng khác có thể root ' t mạo danh.

Có thể giữ bí mật trong bộ nhớ bằng cách chạy các quy trình để thậm chí toàn bộ root không thể truy cập được bằng bất kỳ phương tiện nào không? Những bí mật này có thể được truyền đến các quy trình mới bằng một số phương tiện mà root có thể ảnh hưởng?

Không. Xem câu trả lời ở trên.

Theo định nghĩa, bạn không thể hạn chế quyền truy cập vào root. Nếu bạn giới hạn quyền truy cập của root thì nó không còn là người dùng root nữa.

Nếu tôi muốn từ chối quyền truy cập vào các bí mật, thì tôi sẽ cố gắng che giấu chúng. Các thùng chứa mật mã, có thể ẩn trong bộ nhớ trao đổi hoặc ở một nơi khác và chỉ có thể truy cập bằng mật khẩu hoặc một số loại steganography khác. Thật khó để tìm thấy một cây kim trong đống cỏ khô, mặc dù không phải là không thể.

6
Falcon

Có một số cách gián tiếp thông qua đó root có thể thực thi mã tùy ý. Bạn có thể vô hiệu hóa chúng và thực sự một số khung bảo mật có thể vô hiệu hóa chúng, nhưng chúng làm tê liệt khả năng root để thực hiện các tác vụ quản trị.

Ví dụ, root có thể đọc và ghi vào đĩa trực tiếp, bỏ qua tất cả các cách của quyền hệ thống tập tin. Bạn có thể loại bỏ khả năng này, nhưng sau đó root sẽ không thể di chuyển một hệ thống tập tin đầy đủ sang một đĩa mới trong trường hợp khẩn cấp.

Root có thể tải các mô-đun hạt nhân, và do đó có thể làm mọi thứ mà hạt nhân có thể làm. Bạn có thể loại bỏ khả năng này, nhưng sau đó bạn loại trừ trình điều khiển tải cho phương tiện có thể cắm nóng. (Điều này có thể được mong muốn trong 0,001% cài đặt unix, nhưng đó không phải là trường hợp chung.)

Root có thể cập nhật các tệp thực thi cho phép người dùng đăng nhập, chẳng hạn như login hoặc sshd. Các trình tiện ích này xử lý xác thực người dùng, vì vậy nếu bạn kiểm soát mã của họ, bạn có thể tiêm một cửa hậu. Bạn có thể lấy đi khả năng này, nhưng sau đó root sẽ không thể thực hiện nâng cấp bảo mật.

Root có thể tạo và xóa người dùng và thay đổi thông tin xác thực: nếu bạn có thể chỉnh sửa /etc/passwd để thêm tài khoản, bạn cũng có thể chỉnh sửa tài khoản để tạm thời tạo tài khoản không mật khẩu. Bạn có thể loại bỏ khả năng này bằng cách làm cho một số tệp chỉ đọc ngay cả đối với root, nhưng sau đó bạn sẽ kết thúc với một hệ thống mà bạn không thể tạo hoặc xóa tài khoản người dùng mà không cần khởi động lại.

Các khung bảo mật tạo hiệu quả người dùng root hạn chế, chỉ root trong một tập hợp con của hệ thống - chỉ root trong một máy ảo, không phải trong hệ thống real real. Root giới hạn này mất khả năng thực hiện các nhiệm vụ quản trị trên hệ thống thực. Tôi nghĩ ảo hóa là những gì bạn đang theo đuổi.

Điều này tương đối dễ thực hiện bằng cách sử dụng hệ thống selinux "hai khóa": root không có quyền để làm bất cứ điều gì và một số người dùng khác không có quyền root does, vì vậy, trước tiên bạn cần phải là không root người dùng khác, sau đó bạn "su" để root để thực hiện thay đổi.

Không người dùng nào trong sự cô lập có thể làm hoặc nhìn thấy bất cứ điều gì.

Tôi đang sử dụng cái này. Nó hoạt động thực sự tốt.

3
cnd

Nhu cầu thực tế không được xác định rõ trong câu hỏi, nhưng hai giải pháp tiềm năng được ám chỉ là chưa được đề cập:

  • Hộp đựng
  • HSM

Các thùng chứa - tất nhiên chỉ là một cách tiếp cận hợp lý hơn về mặt kiến ​​trúc đối với những gì đang được thực hiện từng phần với các công cụ như nhà tù và SELinux - có thể có liên quan trong bối cảnh của một câu hỏi được sắp xếp lại - có một cách hợp lý giống như không trộn lẫn hệ thống có thể bị phơi bày trước những kẻ tấn công sao cho nó có thể bị xâm nhập tận gốc nhưng những bí mật trên hệ thống vật lý vẫn được bảo vệ. Với container chúng tôi đang tiến gần đến mục tiêu này. Một bài báo gần đây của nhóm bảo mật NCC rất đáng đọc: https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2016/june/container_whitepaper.pdf

HSM là các thiết bị mã hóa phần cứng ngăn chặn việc truy xuất các khóa giải mã thông qua các phương pháp vật lý hoặc logic, vì vậy có thể là một câu trả lời cho câu hỏi được nêu ra - Tôi có những bí mật mà tôi phải giải mã một cách an toàn, tôi phải làm gì với các khóa.

2
Jonah Benton

Giống như Falcon đã nói, người dùng root theo định nghĩa có quyền truy cập vào tất cả những điều đó, hoặc nó không còn là người dùng root.

Nhân kiểm soát tất cả các phần cứng, vì vậy một khi bạn đã root, bạn có quyền truy cập tương tự. Bạn thực sự cần ảo hóa để người dùng root của bạn chỉ root cho hệ điều hành ảo mà nó đang chạy và một số Hypervisor nằm ngoài đó root. (không nói rằng các nhà ảo thuật không thể khai thác, nhưng những gì bạn đang cố gắng làm là tương đương với điều này).

2
Bradley Kreider

Bạn đã thử Grsecurance chưa? Nó có hiệu quả có thể hạn chế người dùng root theo mọi cách có thể. https://grsecurity.net/

Sự an toàn, kết hợp với PaX làm cho chiếc hộp của bạn trở thành một pháo đài bất khả xâm phạm ... nếu bạn làm đúng

2
Jauzsika