Tại sao các tệp thực thi trong eg / usr / sbin có thể ghi được bằng root?

Bạn có thể giải thích tại sao một tệp được biên dịch nhị phân (ví dụ, trong /usr/sbin) , có quyền ghi cho rootngười dùng không?

Đối với tôi, điều này được biên soạn. Có nghĩa là viết trực tiếp không có sử dụng và có thể khiến tập tin gặp một số vấn đề bảo mật.

Một tập lệnh (ví dụ như một bashtệp) có thể có thể ghi được vì về cơ bản nó là một tệp văn bản, nhưng tại sao nó lại giống với một tệp được biên dịch trong đó không có ghi thực sự cần thiết theo như tôi biết?

Cảm ơn bạn trước phản hồi của bạn.

— t1m0th33
nguồn

Chỉ cần làm rõ, bạn đang tự hỏi tại sao người dùng rootcó quyền ghi vào tệp nhị phân? Nếu không có gì khác nó sẽ giúp khi nâng cấp gói đó.

— Eric Renouf

Lưu ý rằng các tệp nhị phân trớ trêu là các tệp duy nhất mà chúng ta thường viết / chỉnh sửa trực tiếp trên đĩa. Chúng tôi không thể làm điều đó với các tệp văn bản như tập lệnh vì sửa đổi văn bản liên quan đến việc không ghi vào tệp mà thêm các byte bổ sung vào giữa tệp hoặc xóa byte ở giữa tệp. Điều này là không thể làm với fseek fwrite. Vì vậy, đối với các tệp văn bản, chúng ta thường đọc vào RAM sau đó xóa tệp cũ và ghi nội dung của RAM vào đĩa (tức là chúng ta ghi đè lên). Ngoài ra, khi bạn cài đặt, di chuyển hoặc thay thế các tệp thực thi, bạn đang ghi vào đĩa để bạn cần quyền ghi.

— slebetman

@slebetman: Bạn có thể chỉnh sửa trực tiếp các tệp văn bản. Ví dụ, mở tệp, mở rộng tệp, ánh xạ bộ nhớ, sử dụng memmove()để di chuyển phần cuối cùng đến cuối và mở một lỗ, sau đó chèn văn bản mới vào lỗ. Hoặc bạn có thể sử dụng một loạt pread()/ pwrite()để làm tương tự.

— Zan Lynx

@EricRenouf Trên thực tế, không cần phải có quyền ghi trên tệp nhị phân để nâng cấp gói chứa nó. Về nâng cấp gói, nhị phân cũ không được ghi vào; trong thực tế điều này là không thể nếu nhị phân hiện đang chạy (tìm kiếm ETXTBSY). Thay vào đó, nhị phân cũ được loại bỏ và nhị phân mới được ghi vào một tệp mới cùng tên. Xóa các tệp không yêu cầu quyền ghi trên chúng, chỉ trên thư mục chứa (tức là /usr/sbin/).

— marcelm

@marcelm: Nói đúng ra bạn không chỉ đơn thuần sử dụng fseek và viết, bạn đang đệm phần còn lại vào RAM. Bạn cũng có thể đệm phần còn lại vào một tệp khác. Hoặc bạn có thể viết nội dung mới vào một tệp mới. Không ai trong số đó cho phép bạn mở rộng các tệp văn bản mà không cần một số bộ đệm lớn.

— slebetman

Sẽ không thực sự quan trọng nếu các tệp trong /bin(hoặc bất kỳ thư mục tiêu chuẩn nào khác có thể thực thi được) có thể ghi được bằng root hay không. Trên máy chủ Linux tôi đang sử dụng, chúng có thể ghi được bằng root, nhưng trên máy OpenBSD của tôi thì không.

Miễn là họ không thể ghi được bởi nhóm hoặc bởi "người khác"!

Không có vấn đề bảo mật, vd

-rwxr-xr-x 1 root root 126584 Feb 18  2016 /bin/ls

Nếu ai đó muốn ghi đè lên nó, họ sẽ phải root và nếu họ rootvà ghi đè lên nó, thì họ cũng vậy

cài đặt phiên bản mới hoặc
vụng về, hay
một kẻ tấn công với quyền root đã có .

Một điều khác cần xem xét là root có thể ghi vào tệp bất kể nó có được bảo vệ hay không, bởi vì ... root.

Cũng lưu ý rằng "một tập lệnh" cũng giống như một tệp nhị phân. Một tập lệnh không cần phải ghi "vì đó là tệp văn bản". Nếu bất cứ điều gì, nó có lẽ chỉ cần có quyền như các tệp thực thi khác trong cùng thư mục.

Đừng đi thay đổi quyền trên mọi thứ ngay bây giờ! Điều đó có thể phá hỏng tất cả các loại người quản lý gói và có khả năng gây nhầm lẫn, những người có thể xác minh rằng các quyền được đặt đúng. Nó cũng có thể làm cho hệ thống dễ bị tổn thương nếu bạn vô tình thay đổi các quyền sai cách trên ứng dụng quan trọng về bảo mật.

Chỉ cần giả sử rằng các quyền trên các tệp thực thi được đặt chính xác, trừ khi bạn tìm thấy thứ gì đó trông thật kỳ quặc, trong trường hợp đó bạn có thể nên liên hệ với người bảo trì gói có liên quan để xác minh thay vì bắt đầu thay đổi công cụ.

Từ các bình luận và trên trò chuyện , đã có một cuộc gọi cho một số lịch sử.

Lịch sử của các quyền trên nhị phân trên Linux không phải là bất cứ điều gì tôi biết. Có thể suy đoán rằng họ chỉ đơn giản là thừa hưởng các quyền từ thư mục hoặc chỉ từ mặc định umaskcủa Linux, nhưng tôi thực sự không biết.

Những gì tôi biết là OpenBSD cài đặt các nhị phân trong hệ thống cơ sở ¹ với chế độ cấp phép theo mặc định 555 ( -r-xr-xr-x). Điều này được chỉ định trong một đoạn Makefile trong /usr/share/mk/bsd.own.mkđó thiết lập BINMODEthành 555 (trừ khi nó đã được đặt). Sau này được sử dụng khi cài đặt thực thi trong make buildtrong /usr/src.

Tôi đã xem nhật ký CVS có chú thích cho tệp này và thấy rằng dòng này trong tệp không thay đổi do được nhập từ NetBSD vào năm 1995.

Trên NetBSD, tệp lần đầu tiên được đưa vào CVS vào năm 1993, với giá trị BINMODEđược đặt là 555.

Dự án FreeBSD dường như đã sử dụng cùng một tệp chính xác như NetBSD kể từ ít nhất là năm 1994 và với một cam kết sau đó thêm một gợi ý trong thông báo cam kết rằng các tệp cũ là từ bản phát hành 4.4BSD của Bản phân phối phần mềm Berkeley.

Ngoài ra, CSRG tại Berkeley đã giữ các nguồn trong SCCS nhưng kho lưu trữ của chúng có sẵn ở dạng Git trên GitHub ² . Các tập tin mà chúng tôi đang đem lại cho các treatement forencic đây dường như đã được cam kết bởi Keith Bostic (hoặc ai đó trong gần anh ta) vào năm 1990.

Vậy đó là câu chuyện. Nếu bạn muốn tại sao , thì tôi cho rằng chúng ta sẽ phải hỏi Keith. Tôi đã hy vọng nhìn thấy một thông điệp cam kết cho một sự thay đổi nói rằng " điều này cần phải là 555 vì ... ", nhưng không.

¹ _{hệ thống BSD có sự phân chia chặt chẽ hơn thành "hệ thống cơ sở" và "gói bên thứ 3" (cổng / gói) so với Linux. Hệ thống cơ sở là một đơn vị kết hợp cung cấp một bộ đầy đủ các phương tiện để chạy hệ điều hành, trong khi các cổng hoặc gói được xem là "phần mềm cục bộ" và được cài đặt bên dưới /usr/local.}

² _{Một kho lưu trữ GitHub toàn diện hơn về các bản phát hành Unix từ những năm 70 trở đi cũng có sẵn .}

— Kusalananda
nguồn

Cảm ơn bạn đã trả lời. Quyền viết là bình thường vì nó không thực sự quan trọng như là người dùng root (anh ta có thể làm bất cứ điều gì). Nhưng, vì nó không thực sự quan trọng, tại sao chúng ta không đặt quyền viết nếu nó giống như từ đầu? Có phải là quyết định độc đoán?

— t1m0th33

@ t1m0th33 Tôi tin rằng đó có thể là một quyết định tùy tiện mà ai đó đã đưa ra, vâng. Như tôi đã nói, trên hệ thống OpenBSD của tôi, các tệp trong các vị trí đó không thể ghi được root.

— Kusalananda

Tôi không nghĩ đó là một quyết định có ý thức bởi bất cứ ai. Trình quản lý gói mặc định cài đặt tệp với các bit cho phép mà chúng đã kết thúc trong quá trình xây dựng; trong khi xây dựng trình liên kết đã tạo ra các tệp có quyền 755 bởi vì đó là những gì bạn nhận được khi trừ umask từ 777 và gốc umask (trên các máy xây dựng của nhà cung cấp hệ điều hành) có trong khi xây dựng là 022 vì 022 là ô mặc định cho mọi người và thực hiện Nó là 222 cho root sẽ là công việc thêm vô nghĩa.

— Henning Makholm

+1 cho "Đừng đi thay đổi quyền trên mọi thứ ngay bây giờ!" Tôi thấy rất nhiều câu hỏi như vậy trên Hãy hỏi nơi người dùng Ubuntu đã làm chmod -R trên /usrhoặc /var, và ngạc nhiên - họ sudokhông được làm việc hay cái gì khác không hoạt động.

— Sergiy Kolodyazhnyy

Trong lịch sử, việc không có quyền ghi cho root sẽ không có tác dụng (root có thể chmod bất cứ thứ gì, và thậm chí không cần, bởi vì root không bao giờ có được một EPERM khi mở hoặc viết). Tôi tự hỏi nếu công cụ 555 này bắt đầu bởi vì nó thực sự có thể bị hạn chế root (khi nào bảo mật lần đầu tiên xuất hiện? Cùng thời gian với 4.4BSD hoặc đầu 386BSD / NetBSD?)