Người dùng thông thường có thể đọc / etc / passwd, đây có phải là lỗ hổng bảo mật không?

19

ls -l /etc/passwd

cho

$ ls -l /etc/passwd
-rw-r--r-- 1 root root 1862 2011-06-15 21:59 /etc/passwd

Vì vậy, một người dùng bình thường có thể đọc các tập tin. Đây có phải là một lỗ hổng bảo mật?

— Agurwal Ankur
nguồn

49

Băm mật khẩu thực tế được lưu trữ trong /etc/shadowđó, người dùng thông thường không thể đọc được. /etc/passwdgiữ thông tin khác về id người dùng và shell phải được đọc bởi tất cả người dùng để hệ thống hoạt động.

— Michael
nguồn

3

Không thực sự - mật khẩu trong lịch sử đã được giữ trong / etc / passwd - nhưng điều này khiến cho brute-force khớp đơn giản - do đó các hệ thống hiện đại sử dụng / etc / shadon với pam_unix và tương tự.

— symcbean

4

Linux hiện đại sử dụng /etc/shadow. Các BSD sử dụng /etc/master.passwd. Solaris sử dụng /etc/security/passwd. HP-UX sử dụng /.secure/etc/passwdvà danh sách tiếp tục ...

— Chris S

16

Thông thường, mật khẩu băm được lưu trữ /etc/shadowtrên hầu hết các hệ thống Linux:

-rw-r----- 1 root shadow 1349 2011-07-03 03:54 /etc/shadow

(Chúng được lưu trữ /etc/master.passwdtrên các hệ thống BSD .)

Các chương trình cần thực hiện xác thực vẫn cần chạy với các rootđặc quyền:

-rwsr-xr-x 1 root root 42792 2011-02-14 14:13 /usr/bin/passwd

Nếu bạn không thích các setuid rootchương trình và một tệp duy nhất chứa tất cả mật khẩu được băm trên hệ thống của bạn, bạn có thể thay thế nó bằng mô-đun PAM Openwall TCB . Điều này cung cấp cho mỗi người dùng một tệp riêng để lưu trữ mật khẩu băm của họ - kết quả là số lượng setuid rootchương trình trên hệ thống có thể giảm đáng kể.

— xuất hiện
nguồn

13

Mật khẩu đã không được lưu trữ trong /etc/passwdnhiều năm nay; Tên là di sản, chức năng là cơ sở dữ liệu người dùng cục bộ vẫn còn và tất cả phải được đọc cho mục đích đó.

— geekizard
nguồn

2

khả năng đọc thế giới là một quyết định thiết kế, không cần thiết

— Ben Voigt

@Ben: vậy có hợp lý khi không ai có thể xác định các tệp thuộc về người khác? Đó là cửa hàng địa phương cho NSS những ngày này, không phải cho PAM mặc dù tên của nó.

— geekizard

1

Hoàn toàn có thể có một dịch vụ đặc quyền làm uid -> dịch tên, mà không cho phép người dùng không có đặc quyền liệt kê toàn bộ danh sách người dùng. Một số hệ điều hành chọn tùy chọn đó.

— Ben Voigt

1

@joechip Các hệ điều hành hiện tại không được thiết kế để ẩn người dùng với nhau. Tất cả người dùng có thể được liệt kê theo nhiều cách hơn / etc / passwd. ls -la / home trên Linux, ls -la / Người dùng trên MacOS X, dir C: \ Người dùng trong windows 7, ps -afux trong các hệ thống Unix. Thay đổi lựa chọn thiết kế Ben Voigt ám chỉ chỉ làm cho cuộc sống khó khăn mà không thay đổi an ninh.

— Ảo thuật gia

1

@Magicianeer - Chỉ cần nói ví dụ về Windows không hoàn toàn đúng. Bạn có thể đưa người dùng thông qua các phương thức khác, nhưng nhìn vào thư mục người dùng C: \ sẽ chỉ liệt kê những người dùng đã đăng nhập; không phải bất kỳ người dùng hệ thống.

— burnt_hand

6

Ở một mức độ nào đó, như bạn có thể xác định người dùng. Trước đây bạn cũng có thể lấy mật khẩu của họ. Tuy nhiên, một userid thực sự đáng để bẻ khóa là rootnổi tiếng mà không cần tập tin mật khẩu.

Tiện ích của việc có thế giới tập tin mật khẩu có thể đọc được nói chung vượt xa rủi ro. Ngay cả khi nó không thể đọc được trên thế giới, một getent passwdlệnh chức năng sẽ khiến khoảng bảo mật tăng lên.

Khả năng người dùng không root xác định các tệp do người khác sở hữu sẽ biến mất. Có thể xác định được sở hữu (người dùng trong tệp passwd) và các tệp chưa được đặt tên (người dùng không phải trong tệp passwd) có thể hữu ích trong việc xem xét nội dung của hệ thống tệp. Mặc dù có thể giải quyết vấn đề này bằng các setuidchương trình thích hợp , nhưng điều đó sẽ thêm một vectơ tấn công khổng lồ thông qua các chương trình đó.

Cuối cùng, đó là vấn đề về sự cân bằng, và trong trường hợp này tôi sẽ nói rằng sự cân bằng chắc chắn là có thế giới mật khẩu có thể đọc được.

— BillThor
nguồn