Tại sao nên tạo nhóm và người dùng cho một số ứng dụng?


11

Hầu hết thời gian, khi cài đặt một chương trình từ nguồn, nên tạo một người dùng mới và một nhóm mới và cung cấp cho /usr/local/<myapp>người dùng và quyền sở hữu nhóm được tạo gần đây.

  • Tại sao pratice như vậy được coi là một thực hành tốt?

  • Nó cải thiện điều gì?

Ví dụ: nhóm người dùng / mysql mysql cho máy chủ cơ sở dữ liệu MySQL.

Câu trả lời:


11

Thực tiễn không phải là tạo một người dùng và nhóm cho mỗi ứng dụng, mà là cho mỗi dịch vụ. Đó là, các chương trình được thực thi bởi người dùng cục bộ không cần phải được cài đặt như một người dùng khác ngoài root. Đó là trình nền , các chương trình đang chạy trong nền và thực thi các yêu cầu đến qua mạng hoặc các phương tiện liên lạc khác, sẽ chạy như một người dùng chuyên dụng.

Trình nền chạy như một người dùng chuyên dụng để nếu nó hoạt động sai (do lỗi, có thể do kẻ tấn công gây ra) thì thiệt hại có thể bị hạn chế: chỉ các tệp dữ liệu của trình nền bị ảnh hưởng (trừ khi kẻ tấn công tìm được lỗ hổng cục bộ , có thể xảy ra). Ví dụ, daemon cơ sở dữ liệu mysqldchạy như một người dùng và nhóm chuyên dụng mysql:mysqlvà các tệp dữ liệu của cơ sở dữ liệu ( /var/lib/mysql/*) thuộc về mysql:mysql.

Lưu ý rằng daemon thực thi và các tệp cấu hình và dữ liệu tĩnh khác được sử dụng nhưng không được sửa đổi bởi daemon không được thuộc về người dùng chuyên dụng; chúng nên được sở hữu bởi root:root, giống như hầu hết các tệp chương trình và cấu hình. Các mysqldquá trình không có ghi đè kinh doanh /usr/sbin/mysqldhay /etc/mysql/my.cnf, vì vậy những tập tin này phải không thuộc về những mysqlngười sử dụng hoặc có khả năng ghi bởi mysqlngười dùng hoặc mysqlnhóm. Nếu một số tệp chỉ có thể đọc được bởi trình nền và quản trị viên, thì chúng phải được sở hữu bởi người dùng gốc và nhóm chuyên dụng và có chế độ 0640 ( rw-r-----).

Một loại đặc biệt của các tệp thực thi không thể thuộc sở hữu của root:rootcác chương trình là các chương trình được người dùng gọi ra nhưng cần phải chạy với các đặc quyền bổ sung. Các tệp thực thi này phải là root setuid nếu chúng cần chạy (ít nhất là một phần) với quyền root; thì tệp thực thi phải có chế độ 4755 ( rwsr-xr-x). Nếu chương trình cần với các đặc quyền bổ sung nhưng không phải là root, thì chương trình nên được tạo ra setgid, để các đặc quyền bổ sung đi qua một nhóm chứ không phải thông qua người dùng. Việc thực thi sau đó có chế độ 2755 ( rwxr-sr-x). Những lý do có hai mặt:

  • Không thể cho phép thực thi chính nó, để nếu người dùng quản lý khai thác lỗ hổng, họ có thể sửa đổi các tệp dữ liệu được sử dụng bởi chương trình nhưng không tiêm ngựa trojan vào tệp thực thi để tấn công người dùng khác đang chạy chương trình .
  • Tệp dữ liệu của tệp thực thi thuộc về nhóm. Một chương trình setuid sẽ phải chuyển đổi giữa người dùng thực (người dùng đã gọi chương trình) để tương tác với người dùng và với người dùng hiệu quả (người dùng mà chương trình đang chạy) để truy cập các tệp dữ liệu riêng tư của nó (lý do cho nó để có thêm đặc quyền). Một chương trình setgid có thể phân tách thêm dữ liệu theo người dùng chỉ có thể truy cập được vào nhóm (ví dụ: bằng cách lưu trữ các tệp do người dùng sở hữu trong một thư mục chỉ có thể truy cập vào root và nhóm của chương trình).

3

Nó không phải là các ứng dụng nói chung, nhưng daemon mà nó là dành cho. Lý do là vì daemon có thể chạy như một người dùng không có quyền thay vì root để nếu nó có lỗ hổng bảo mật và bị xâm phạm, thiệt hại có thể được thực hiện chỉ dành cho các khu vực mà người dùng có quyền truy cập.


1

Lý do nó được coi là một thông lệ tốt là để ngăn người dùng khác của hệ thống ghi đè lên các tệp dữ liệu và cấu hình cho ứng dụng cụ thể.

Như một ví dụ mysql/ mysqllà chủ sở hữu của bộ lưu trữ cho các tệp cơ sở dữ liệu mysql ngăn mọi người không sử dụng API ứng dụng làm hỏng cơ sở dữ liệu. Thêm vào đó, người dùng mysqlthường không có vỏ thật để không ai có thể đăng nhập như người dùng đó.


Bạn đã bỏ lỡ một điểm quan trọng, đó là đó là những gì người dùng và nhóm ứng dụng đang chạy trên vấn đề đó, và các tệp tĩnh có thể thực thi và khác phải được sở hữu bởi root.
Gilles 'SO- ngừng trở nên xấu xa'

@Gilles Chúng có thể được sở hữu bởi root và hầu hết các ứng dụng được cài đặt thông qua các bản phân phối nhưng chúng không cần phải có và chúng không phải như vậy. Như một vấn đề thực tế /usr/bin/atđược sở hữu bởi daemon/daemontrên Ubuntu
Karlson

1
atkhông phải là daemon. Nó được thiết lập daemonđể nó có thể giao tiếp với atddaemon thông qua các tệp riêng tư.
Gilles 'SO- ngừng trở nên xấu xa'

1

Tạo một nhóm / người dùng mới cho một trình nền mới được cài đặt sẽ cải thiện bảo mật. Khi quy trình máy chủ được chạy dưới một người dùng như vậy, nó bị hạn chế quyền truy cập của người dùng đó. Trong so sánh: khi nó được chạy như root nó có thể làm mọi thứ.

Sự khác biệt này rất quan trọng trong trường hợp trình nền của bạn bị cấu hình sai và / hoặc có lỗi liên quan đến bảo mật.

Tôi không chắc ý của bạn là gì với phần thứ hai của câu hỏi của bạn, tức là phần về /usr/localquyền sở hữu. Nói chung, không có nghĩa là cùng một người dùng Xmà daemon chạy vì lý do bảo mật cũng sở hữu thư mục với các nhị phân (vì trong trường hợp đó, nó có thể thay đổi chúng trong trường hợp khai thác). Nhưng thư mục chứa các tệp dữ liệu mà trình nền hoạt động trên có thể truy cập được bằng cách X- cách dễ nhất để định cấu hình này là tạo Xchủ sở hữu của các thư mục / tệp dữ liệu.

Chạy một daemon dưới người dùng đặc biệt của riêng nó chỉ là một kỹ thuật bảo mật, các kỹ thuật khác bao gồm một số loại 'chroot' hoặc sử dụng hệ thống kiểm soát truy cập bắt buộc (MAC) (ví dụ: SELinux).


1

Đây là một xem xét an ninh. Nó giới hạn thiệt hại có thể được thực hiện bởi một người nào đó đột nhập vào ứng dụng daemon. Ứng dụng người dùng thường được sở hữu bởi một userid tiêu chuẩn như root.

Nếu máy chủ web, máy chủ thư và cơ sở dữ liệu của bạn đều chạy như cùng một người dùng, điều đó sẽ giúp bạn dễ dàng thỏa hiệp hơn. Nếu bất kỳ một trong số chúng có lỗi hoặc cấu hình sai cho phép truy cập hệ thống, quyền truy cập đó có thể được sử dụng để truy cập cả ba ứng dụng.

Nếu tất cả họ đều có tài khoản riêng, như được khuyến nghị, chỉ có ứng dụng bị xâm nhập mới có khả năng truy cập được. Mặc dù chi tiết cấu hình công khai của người khác có thể được đọc, không chắc là những thay đổi có thể được thực hiện.

Nhiều trình tiện ích cho phép người dùng tải lên và tải xuống các tệp và thực hiện những việc mà bạn không muốn họ có thể thực hiện đối với các cấu hình cho các trình tiện ích khác. Nếu mỗi ứng dụng có userid riêng và nhóm thì việc bảo mật daemon sẽ đơn giản hơn.

Có một nhóm cụ thể của daemon giúp đơn giản hơn khi cấp một cách an toàn một daemon truy cập chỉ đọc vào các tệp và thư mục. Nếu tệp hoặc thư mục được sở hữu bởi một người dùng khác, nhưng thuộc nhóm daemon, nó thường sẽ có thể truy cập được chỉ đọc. Quyền truy cập có thể dễ dàng được xác minh và sửa chữa bằng các công cụ như find.


Bạn đã bỏ lỡ một điểm quan trọng, đó là đó là những gì người dùng và nhóm ứng dụng đang chạy trên vấn đề đó, và các tệp tĩnh có thể thực thi và khác phải được sở hữu bởi root.
Gilles 'SO- ngừng trở nên xấu xa'

@Gilles: Lưu ý và chỉnh sửa cho phù hợp.
BillThor
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.