Làm thế nào fakeroot không phải là một vi phạm bảo mật trong Linux?


18

Sau khi đọc một số câu trả lời khá hay từ câu hỏi này , tôi vẫn còn mơ hồ về lý do tại sao bạn muốn giả vờ rằng bạn là root mà không nhận được bất kỳ lợi ích nào của việc thực sự là root.

Cho đến nay, những gì tôi có thể thu thập là fakeroot được sử dụng để trao quyền sở hữu cho một tệp cần được root khi nó được giải nén / tar'ed. Câu hỏi của tôi, là tại sao bạn không thể làm điều đó với chown?

Một cuộc thảo luận của Google Groups ở đây chỉ ra rằng bạn cần fakeroot để biên dịch kernel Debian (nếu bạn muốn làm điều đó từ một người dùng không có đặc quyền). Nhận xét của tôi là, lý do bạn cần phải root để biên dịch có lẽ là vì quyền đọc không được đặt cho người dùng khác. Nếu đó không phải là vi phạm bảo mật mà fakeroot cho phép biên dịch (có nghĩa là gcc bây giờ có thể đọc tệp dành cho root)?

Câu trả lời này ở đây mô tả rằng các cuộc gọi hệ thống thực tế được thực hiện với uid / gid thực sự của người dùng , vậy một lần nữa fakeroot giúp ở đâu?

Làm thế nào để fakeroot ngăn chặn sự leo thang đặc quyền không mong muốn trên Linux? Nếu fakeroot có thể lừa tar để tạo một tập tin được sở hữu bởi root, tại sao không làm điều gì đó tương tự với SUID?

Từ những gì tôi đã thu thập được, fakeroot chỉ hữu ích khi bạn muốn thay đổi chủ sở hữu của bất kỳ tệp gói nào mà bạn đã xây dựng để root. Nhưng bạn có thể làm điều đó với chown, vậy tôi đang thiếu hiểu biết về việc thành phần này được sử dụng ở đâu?


1
Bạn không cần fakeroot để biên dịch kernel. Hệ thống xây dựng kernel không điên đến thế. Các cuộc thảo luận được liên kết là về việc tạo một gói kernel Debian , trong đó việc xây dựng kernel thực sự chỉ là một bước.

@ WumpusQ.Wumbley tôi sẽ sửa nó, và bạn có thể cho tôi biết tại sao lại như vậy không?
ng.newbie

Bởi vì fakeroot là một thứ Debian và Linux còn hơn Debian?

@ WumpusQ.Wumbley nó nên chạy trên bất kỳ phân phối nào.
dùng253751

Câu trả lời:


33

Cho đến nay, những gì tôi có thể thu thập là fakeroot được sử dụng để trao quyền sở hữu cho một tệp cần được root khi nó được giải nén / tar'ed. Câu hỏi của tôi, là tại sao bạn không thể làm điều đó với chown?

Bởi vì bạn không thể làm điều đó với chown, ít nhất là không phải là người dùng không root. (Và nếu bạn đang chạy với quyền root, bạn không cần fakeroot.) Đó là toàn bộ vấn đề fakeroot: cho phép các chương trình được mong đợi chạy bằng root để chạy như một người dùng bình thường, trong khi giả vờ rằng các hoạt động yêu cầu root thành công.

Điều này thường được sử dụng khi xây dựng một gói, để quá trình cài đặt gói được cài đặt có thể tiến hành mà không gặp lỗi (ngay cả khi nó chạy chown root:root, hoặc install -o root, v.v.). fakerootnhớ quyền sở hữu giả mà nó giả vờ cung cấp cho các tệp, vì vậy các hoạt động tiếp theo nhìn vào quyền sở hữu sẽ thấy điều này thay vì quyền sở hữu thực sự; điều này cho phép các tarlần chạy tiếp theo chẳng hạn để lưu trữ các tệp như sở hữu của root.

Làm thế nào để fakeroot ngăn chặn sự leo thang đặc quyền không mong muốn trên Linux? Nếu fakeroot có thể lừa tar để tạo một tập tin được sở hữu bởi root, tại sao không làm điều gì đó tương tự với SUID?

fakeroot không lừa tar làm bất cứ điều gì, nó bảo tồn các thay đổi mà bản dựng muốn thực hiện mà không để những thay đổi đó có hiệu lực trên hệ thống lưu trữ bản dựng. Bạn không cần fakerootphải tạo một tarball chứa tệp thuộc sở hữu của root và suid; nếu bạn có một tệp nhị phân evilbinary, đang chạy tar cf evil.tar --mode=4755 --owner=root --group=root evilbinary, như một người dùng thông thường, sẽ tạo ra một tarball chứa evilbinary, được sở hữu bởi root và suid. Tuy nhiên, bạn sẽ không thể trích xuất tarball đó và duy trì các quyền đó trừ khi bạn làm như vậy với quyền root: không có sự leo thang đặc quyền nào ở đây. fakerootlà một đặc ân decông cụ -escalation: nó cho phép bạn chạy một bản dựng như một người dùng thông thường, trong khi vẫn giữ được các hiệu ứng mà bản dựng sẽ có nếu nó được chạy dưới quyền root, cho phép các hiệu ứng đó được phát lại sau đó. Áp dụng các hiệu ứng mà người dùng thực sự luôn yêu cầu quyền root; fakerootkhông cung cấp bất kỳ phương pháp nào để có được chúng.

Để hiểu việc sử dụng fakerootchi tiết hơn, hãy xem xét rằng một bản dựng phân phối điển hình bao gồm các hoạt động sau (trong số nhiều hoạt động khác):

  • cài đặt tập tin, thuộc sở hữu của root
  • ...
  • lưu trữ các tệp đó, vẫn thuộc sở hữu của root, để khi chúng được giải nén, chúng sẽ được sở hữu bởi root

Phần đầu tiên rõ ràng thất bại nếu bạn không root. Tuy nhiên, khi chạy dưới fakeroot, như một người dùng bình thường, quá trình trở thành

  • cài đặt các tệp, được sở hữu bởi root - điều này không thành công, nhưng fakerootgiả vờ nó thành công và ghi nhớ quyền sở hữu đã thay đổi
  • ...
  • lưu trữ các tệp đó, vẫn thuộc quyền sở hữu của root - khi tar(hoặc bất kỳ trình lưu trữ nào đang được sử dụng) hỏi hệ thống quyền sở hữu tệp là gì, fakerootthay đổi câu trả lời để phù hợp với quyền sở hữu được ghi lại trước đó

Do đó, bạn có thể chạy gói xây dựng mà không cần root, trong khi nhận được kết quả tương tự bạn nhận được nếu bạn thực sự chạy bằng root. Sử dụng fakerootsẽ an toàn hơn: hệ thống vẫn không thể làm bất cứ điều gì mà người dùng của bạn không thể làm, do đó, quá trình cài đặt giả mạo không thể làm hỏng hệ thống của bạn (ngoài việc chạm vào các tệp của bạn).

Trong Debian, các công cụ xây dựng đã được cải thiện để không yêu cầu điều này nữa và bạn có thể xây dựng các gói mà không cầnfakeroot . Điều này được hỗ trợ bởi dpkgtrực tiếp với Rules-Requires-Rootchỉ thị (xem rootless-builds.txt).

Để hiểu mục đích fakerootvà các khía cạnh bảo mật của việc chạy như root hay không, có thể giúp xem xét mục đích của việc đóng gói. Khi bạn cài đặt một phần mềm từ nguồn, để sử dụng trên toàn hệ thống, bạn tiến hành như sau:

  1. xây dựng phần mềm (có thể được thực hiện mà không có đặc quyền)
  2. cài đặt phần mềm (cần được thực hiện dưới quyền root hoặc ít nhất là người dùng được phép ghi vào các vị trí hệ thống phù hợp)

Khi bạn đóng gói một phần mềm, bạn sẽ trì hoãn phần thứ hai; nhưng để thực hiện thành công, bạn vẫn cần cài đặt phần mềm, cài đặt phần mềm, thay vì vào hệ thống. Vì vậy, khi bạn đóng gói phần mềm, quy trình sẽ trở thành:

  1. xây dựng phần mềm (không có đặc quyền)
  2. giả vờ cài đặt phần mềm (một lần nữa không có đặc quyền)
  3. chụp cài đặt phần mềm dưới dạng gói (ditto)
  4. làm cho gói có sẵn (ditto)

Bây giờ người dùng hoàn tất quy trình bằng cách cài đặt gói, cần được thực hiện dưới quyền root (hoặc một lần nữa, người dùng có các đặc quyền phù hợp để ghi vào các vị trí thích hợp). Đây là nơi thực hiện quy trình đặc quyền bị trì hoãn và là phần duy nhất của quy trình cần các đặc quyền đặc biệt.

fakeroot giúp với các bước 2 và 3 ở trên bằng cách cho phép chúng tôi chạy các quy trình cài đặt phần mềm và nắm bắt hành vi của chúng mà không cần chạy bằng root.


1
@ ng.newbie Nếu bạn muốn một lời giải thích khác: tôi hoàn toàn có thể sử dụng trình soạn thảo hex để xây dựng thủ công một tệp tar chứa các tệp thuộc sở hữu gốc hoặc với bất kỳ quyền nào khác có thể. Rốt cuộc, nó chỉ là một số thông tin được gói lại, nó không có bất kỳ sức mạnh nào cho đến khi tập tin thực sự tồn tại trên hệ thống.
mbrig

@ ng.newbie Bạn có gỡ rối nó bằng fakeroot hay không có fakeroot?
dùng253751

2
@ ng.newbie, ngoài ra, nếu bạn muốn tạo một tarball với nhị phân gốc suid cho mục đích độc hại, bạn có thể làm điều đó trên một số máy khác dưới dạng root thực, sau đó sao chép nó vào mục tiêu. Không cần fakeroot ở đó. fakeroot chỉ là một công cụ giúp tạo tập tin tar, nó loại bỏ nhu cầu sử dụng tar --mode --ownercho mỗi và mọi tập tin được thêm vào kho lưu trữ (và cũng hoạt động với các chương trình khác). Các vấn đề tiềm ẩn xảy ra nếu / khi bạn giải nén tệp tar không tin cậy hoặc lưu trữ dưới dạng root, không phải khi tạo tệp.
ilkkachu

7

KHÔNG. Root giả cho phép bạn chạy các công cụ báo cáo và thao tác cấp phép, nó sẽ báo cáo một cách nhất quán. Tuy nhiên, nó sẽ không thực sự cấp các quyền này. Nó sẽ trông giống như bạn có chúng (giả). Nó sẽ không thay đổi bất cứ điều gì bên ngoài môi trường.

Sẽ rất hữu ích, nếu bạn muốn tạo cấu trúc thư mục, chứa quyền sở hữu và quyền, mà người dùng của bạn không thể đặt, sau đó bạn sẽ tar, zip hoặc gói khác.

không thực sự nâng cao quyền, nó là giả. Nó không cho phép bạn làm bất cứ điều gì (xóa, viết, đọc) mà bạn không thể làm. Bạn có thể sản xuất gói (theo lý thuyết) mà không cần nó. Bạn có thể nhận được một báo cáo giả ( ls) mà không có nó.

Đó không phải là một lỗ hổng bảo mật, bởi vì nó không cho phép truy cập, hoặc bất cứ điều gì bạn không thể làm mà không có nó. Nó chạy mà không có đặc quyền. Tất cả liều lượng của nó là chặn các cuộc gọi đến chown, chmodv.v ... Nó làm cho chúng không hoạt động, ngoại trừ việc nó ghi lại những gì sẽ xảy ra. Nó cũng chặn các cuộc gọi đến statvv để nó báo cáo quyền và quyền sở hữu, từ cơ sở dữ liệu nội bộ của chính nó, như thể các lệnh khác đã được thực hiện. Điều này rất hữu ích, bởi vì nếu sau đó bạn nén thư mục, nó sẽ có quyền giả mạo. Nếu sau đó bạn giải nén, với quyền root, thì các quyền sẽ trở thành hiện thực.

Bất kỳ tệp nào không thể đọc / ghi được trước đó, sẽ vẫn không thể đọc / ghi được. Bất kỳ tệp đặc biệt nào (ví dụ như thiết bị) được tạo, sẽ không có quyền hạn đặc biệt. Bất kỳ set-uid nào (cho người dùng khác), các tệp sẽ không set-uid. Bất kỳ sự leo thang đặc quyền khác sẽ không hoạt động.

Đây là một loại máy ảo: Nói chung, một máy ảo có thể mô phỏng mọi môi trường / HĐH, nhưng không thể làm gì với máy chủ, điều mà bất kỳ ứng dụng nào khác không thể làm được. Trong máy ảo, bạn có thể làm bất cứ điều gì. Bạn có thể phát minh lại hệ thống bảo mật giống hoặc khác, tuy nhiên tất cả điều này sẽ tồn tại trên máy chủ, vì tài nguyên thuộc sở hữu của người dùng / nhóm của quá trình chạy môi trường ảo.


@ ctrl-alt-decor Như tôi đã hỏi trong nhận xét trên, trong * nix không thể đặt chủ sở hữu để root từ một người dùng không có đặc quyền khác, đúng không? Vì vậy, phải có một lý do chính đáng cho điều đó nếu một chương trình cho phép nó, làm thế nào nó không phải là một lỗ hổng bảo mật?
ng.newbie

@ ctrl-alt-decor fakeroot không cho phép tôi đọc / ghi / xóa, nhưng nếu tôi viết một trình bao bọc cho các tòa nhà thì nó có lý do để tôi có thể thực hiện các thao tác đó.
ng.newbie

@ ctrl-alt-decor Vì vậy, lý do duy nhất để fakeroot tồn tại là đặt quyền cho một tệp thành root mà không phải là root. Nếu đó không phải là một lỗ hổng bảo mật thì tại sao Linux lại không cho phép điều đó ngay từ đầu?
ng.newbie

1
Không, nó cho phép bạn giả mạo cài đặt người dùng cho bất kỳ người dùng nào và giả mạo một số thứ khác. Hãy thử: chạy fakeroot và xem các tệp từ bên ngoài, thử truy cập các tệp mà bạn không nên.
ctrl-alt-delor

4

Đã có hai câu trả lời hay và rất chi tiết ở đây, nhưng tôi sẽ chỉ ra rằng đoạn giới thiệu của người đàn ông gốc fakeroot trang 1 thực sự giải thích nó khá rõ ràng và chính xác:

fakeroot chạy một lệnh trong một môi trường trong đó nó dường như có quyền root để thao tác tệp. Điều này hữu ích để cho phép người dùng tạo tài liệu lưu trữ (tar, ar, .deb, v.v.) với các tệp trong đó có quyền / quyền sở hữu gốc. Nếu không có fakeroot, người ta sẽ cần phải có quyền root để tạo các tệp cấu thành của tài liệu lưu trữ với quyền và quyền sở hữu chính xác, sau đó đóng gói chúng, hoặc người ta sẽ phải xây dựng tài liệu lưu trữ trực tiếp mà không cần sử dụng bộ lưu trữ.

Fakeroot cho phép người dùng không phải root tạo tài liệu lưu trữ chứa các tệp thuộc sở hữu gốc, đây là một phần quan trọng trong việc tạo và phân phối các gói phần mềm nhị phân trong Linux. Nếu không fakeroot, lưu trữ gói sẽ phải được tạo trong khi chạy dưới dạng root thực tế, để chúng chứa quyền sở hữu và quyền của tệp chính xác. Đó sẽ là một rủi ro bảo mật. Xây dựng và đóng gói phần mềm có khả năng không tin cậy là một sự phơi bày rất lớn nếu được thực hiện với các quyền riêng tư gốc. Nhờ fakeroot, một người dùng không có đặc quyền với các tệp không có đặc quyền vẫn có thể tạo tài liệu lưu trữ chứa các tệp có quyền sở hữu gốc. 2

Nhưng đó không phải là một rủi ro bảo mật, bởi vì không có gì trong kho lưu trữ thực sự thuộc quyền sở hữu của root cho đến khi các tệp được EXTRACTED . Và thậm chí sau đó, các tệp sẽ chỉ được trích xuất với quyền gốc của chúng nếu nó được thực hiện bởi người dùng đặc quyền. Bước đó - nơi fakerootlưu trữ được lưu trữ có chứa các tệp "gốc" được trích xuất bởi người dùng đặc quyền - là nơi gốc "giả" cuối cùng trở thành hiện thực. Cho đến thời điểm đó, không có đặc quyền gốc thực sự nào được lấy hoặc bỏ qua.

Ghi chú

  1. Fakeroot đã sinh ra một số đối thủ / kẻ bắt chước sẽ giả trang như fakerootthể được cài đặt, bao gồm fakeroot-ngpseudo. Nhưng IMHO không phải trang người đàn ông "bắt chước" gần như rõ ràng về việc đi thẳng vào vấn đề trong câu hỏi này. Gắn bó với bản gốc, một và chỉ fakerootOG
  2. Các hệ thống phân phối / đóng gói khác khắc phục điều này bằng cách đơn giản là không sử dụng quyền sở hữu gốc trong kho lưu trữ gói của họ. Ví dụ, trên Fedora, phần mềm có thể được biên dịch, cài đặt và đóng gói bởi người dùng không có đặc quyền mà không yêu cầu fakeroot. Tất cả đều được thực hiện trong $HOME/rpmbuild/không gian của người dùng và các bước make installđược ưu tiên thông thường như được chuyển hướng (thông qua các cơ chế như --prefixDESTDIR) đến một $HOME/rpmbuild/BUILDROOT/hệ thống phân cấp có thể được coi là một loại không gian "fakechroot" (mà không thực sự sử dụng fakechroot).

    Nhưng ngay cả trong thời gian make install, mọi thứ đều được thực thi và được sở hữu bởi người dùng không có quyền. Quyền sở hữu và quyền được trích xuất tệp sẽ được đặt thành root,root0644(hoặc 0755cho các tệp thực thi) theo mặc định, trừ khi bị ghi đè trong .spectệp định nghĩa gói ( ) trong trường hợp chúng được lưu trữ dưới dạng siêu dữ liệu trong gói cuối cùng. Bởi vì không có quyền hoặc quyền sở hữu thực sự được áp dụng cho đến khi quá trình cài đặt (đặc quyền) của gói vòng / phút, không cần root cũng không fakerootcần thiết trong quá trình đóng gói. Nhưng fakerootthực sự chỉ là một con đường khác nhau cho cùng một kết quả.


1
Về ghi chú đầu tiên của bạn, fakeroot-ng yêu cầu thay thế fakeroot, nhưng trên thực tế, nó đã không thay thế nó và AFAIK fakerootvẫn là công cụ được sử dụng trong Debian theo mặc định (khi cần thiết).
Stephen Kitt

@StephenKitt Aha! Cảm ơn. Tôi đã tự hỏi về điều đó. Ban đầu, tôi đã bối rối vì tôi đã tìm kiếm fakeroottrang này và Google đã bỏ rơi tôi tại fakeroot-ng(giả dạng như fakeroot(1)) và tôi đoán rằng tôi đã đánh giá quá cao. Nhưng tôi thấy rằng fakeroot-ng chưa được cập nhật từ năm 2014 , trong khi fakeroot vẫn hoạt động . Rõ ràng cũng có giả giả đã làm cho nó một vài năm trước đây, nhưng bây giờ đã bị đình trệ. Tôi sẽ điều chỉnh câu trả lời của mình cho phù hợp.
FeRD

1
Vâng tôi đã nhầm lẫn lúc đầu cũng vậy, kể từ khi các fakerootmanpage trên trang web của Debian dẫn đến fakeroot-ngphiên bản 's theo mặc định. Kiểm tra đoạn cuối của fakeroot-ngmột twist thú vị ;-).
Stephen Kitt
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.