Điểm:7

Cấp quyền cho người dùng không phải root để sử dụng một cổng

lá cờ jp

Tôi lưu trữ một máy chủ phòng thí nghiệm nơi tôi là người chủ (và là người dùng thông thường).

Tên miền là example.org và tôi cung cấp cho mỗi thành viên một tên miền phụ, ví dụ như bob.example.org cho Bob và anna.example.org cho người dùng Anna. Tôi nghĩ rằng bạn có được thỏa thuận. :) Các tên miền phụ được đảo ngược proxy bằng cách sử dụng nginx tới một cổng cụ thể.

Câu hỏi của tôi là, có cách nào để tôi có thể cấp quyền cho người dùng không phải root bắt đầu bộ chứa docker trên phạm vi cổng cụ thể của họ không. Ví dụ: Anna được cung cấp phạm vi 1300-1350 trong đó cổng 1300 được liên kết với anna.example.org và các cổng khác được đặt trước.

Hệ thống chạy Debian 11 Bullseye và phiên bản Docker mới nhất.

Cyclic3 avatar
lá cờ br
Tôi sẽ *rất* cẩn thận về việc cấp cho người dùng không phải root quyền truy cập vào docker.Nó đơn giản như `docker run -v /:/pwn -it cycl3/pwn` để có quyền truy cập r/w hoàn chỉnh vào toàn bộ hệ thống tệp và việc thêm `--privileged` gần như giống hệt về mặt chức năng với quyền root trên máy đó . Tôi đã thấy điều này xảy ra rất nhiều lần, bao gồm cả trong một CTF do một công ty mạng lớn điều hành, nơi nó được thiết kế cho một thử thách duy nhất, nhưng cuối cùng lại để lộ tất cả các máy được sử dụng cho danh mục đó. Nó có thể được thực hiện một cách an toàn, nhưng tôi nghĩ điều thực sự quan trọng là phải nhấn mạnh điều này có thể đi bao xa về phía nam.
Oscar Andersson avatar
lá cờ jp
Nhận xét tuyệt vời về giai thoại CTF. Tôi đôi khi cạnh tranh trong những bản thân mình. Âm thanh giống như một cuộc thi thú vị mà một! :) Dù sao, tôi đã quyết định cách ly hoàn toàn người dùng bằng cách sử dụng các vùng chứa khác nhau mà không có bất kỳ quyền truy cập nào vào máy chủ ngoại trừ một số cổng mở. Cảm ơn vì đã dành thời gian cho tôi.
Điểm:9
lá cờ td
bob

AFAIK Linux chỉ có khái niệm cổng đặc quyền so với cổng không có đặc quyền.

Tham số điều chỉnh nhân Linux net.ipv4.ip_unprivileged_port_start xác định cổng nào được đặc quyền. Tất cả các cổng từ 0 đến net.ipv4.ip_unprivileged_port_start được ưu đãi.

Các cổng đặc quyền chỉ có thể được sử dụng bởi các quy trình được bắt đầu bởi người dùng root hoặc có quyền root hoặc bởi các quy trình được chỉ định khả năng CAP_NET_BIND_SERVICE với ví dụ sudo setcap cap_net_bind_service=ep /path/bin/application

Tất cả các cổng khác không có đặc quyền và có thể được sử dụng bởi bất kỳ người dùng nào, miễn là các cổng đó chưa được sử dụng.

Tôi không biết bất kỳ phương pháp thay thế nào để cho phép người dùng cụ thể sử dụng các cổng cụ thể.

Oscar Andersson avatar
lá cờ jp
Cảm ơn @bob! Tôi đang nghĩ đến việc cung cấp cho mỗi người dùng một bộ chứa docker với Debian 11 để họ có thể tự do chuyển vùng, sau đó tôi liên kết cổng 80 và 22 với một miền phụ của miền chính của mình. Bạn nghĩ gì về điều này? Có lẽ nó thêm một lớp bảo mật.
Điểm:6
lá cờ in

Trước hết, chỉ những người dùng đáng tin cậy mới được phép kiểm soát daemon Docker của bạn

Trình nền docker chạy với quyền root theo mặc định trên bản cài đặt Debian Bullseye. Thêm người dùng vào người đóng tàu nhóm cấp cho người dùng đó quyền truy cập root psuedo do có quyền kiểm soát trình nền docker có lượng truy cập đó. Mọi người dùng trong nhóm docker sẽ có toàn quyền kiểm soát máy chủ và các vùng chứa khác và có thể chạy một vùng chứa --công bốlà bất kỳ cổng nào.

Có một số tùy chọn để cung cấp bảo mật cho quyền truy cập docker của người dùng.

  1. docker không root
  2. sudo
  3. API

1. Docker không root

Một thiết lập docker không root sẽ cho phép mỗi người dùng chạy docker deamon. Đối với các cổng thấp hơn 1024, nó sẽ cần phải tuân theo thông tin cổng không có đặc quyền bob được cung cấp vì mỗi người dùng sẽ "sở hữu" deamon của riêng họ. Docker cũng cung cấp hướng dẫn liên quan. Điều này sẽ không ngăn Anna lấy cảng Bobs.

2. sudo

Phương pháp đơn giản nhất để cho phép người dùng chạy các lệnh docker là cung cấp một tập lệnh được kiểm soát gốc thông qua Sudo là tĩnh hoặc kiểm soát đầu vào của người dùng cho các đối số tùy chọn:

#!/bin/bash
docker run --detach --publish 1300:1300 anna/app-image
anna TẤT CẢ=(root) NOPASSWD: /usr/local/bin/start-anna-image

Nếu bạn muốn người dùng có thể thêm các tùy chọn của riêng họ, bạn cần phải rất cẩn thận trong việc kiểm soát đầu vào của họ vì rất dễ

3. Plugin ủy quyền hoặc API cho Docker

Vì Docker không cung cấp bất kỳ lớp ủy quyền nào trên daemon nên bạn cần thêm thứ gì đó để kiểm soát quyền truy cập của người dùng.

Docker cung cấp một bản dựng sẵn plugin ủy quyền framework để kích hoạt tính năng này. Một số ví dụ opa-docker-authzcasbin-authz-plugin

Bạn có thể cấp cho người dùng quyền truy cập vào một dạng API proxy cung cấp xác thực và ủy quyền đối với những gì được chuyển cho Docker REST API. Có các thư viện docker cho hầu hết các ngôn ngữ lập trình.Kubernetes+RBAC là một ví dụ về API nằm trước trình nền Docker và kiểm soát quyền truy cập (chỉ là một API rất lớn/phức tạp làm được nhiều hơn thế).

Oscar Andersson avatar
lá cờ jp
Cảm ơn @matt, thực sự! Bạn đã đưa ra một số điểm tốt, hiện tôi đã thử phương án 1 và 2. Tôi cảm thấy docker không root hơi quá phức tạp đối với tôi và bộ quy tắc sudo đòi hỏi quá nhiều thời gian đối với tôi. Bạn nghĩ gì về việc cung cấp cho mỗi người dùng vùng chứa riêng mà họ chỉ cần SSH vào. Phạm vi người dùng thậm chí không bao gồm máy chủ lưu trữ. Theo bạn, những lợi ích bảo mật của việc này là gì? Cảm ơn.
Điểm:5
lá cờ cn

Miễn là các cổng không có đặc quyền, người dùng không phải root có thể liên kết với bất kỳ cổng nào (trên 1024). Họ có thể khởi động các thùng chứa bằng:

docker run --expose 1300-1350 <tên hình ảnh>

Nó là lần đầu tiên đến trước được phục vụ. Nếu hai chương trình đang cố liên kết với cùng một cổng, chỉ chương trình đầu tiên liên kết sẽ thành công.

Đối với các cổng đặc quyền (dưới 1024), bạn cần có khả năng root hoặc CAP_NET_BIND_SERVICE. Nhìn thấy khả năng của con người để biết chi tiết.

Oscar Andersson avatar
lá cờ jp
Cảm ơn Mica! Tôi có thể thêm người dùng không phải root vào nhóm người dùng docker và không để họ can thiệp vào các cổng đặc quyền và các vùng chứa khác không? Vì vậy, Anna không thể xem, chỉnh sửa hoặc xóa các vùng chứa của Bob.
lá cờ cn
Các vùng chứa được bắt đầu bởi một người dùng sẽ chỉ được quản lý bởi người dùng đó. Bạn có thể giới hạn phạm vi cổng mà các bộ chứa (hoặc bất kỳ ứng dụng nào) có thể liên kết qua SELinux hoặc AppArmor: https://serverfault.com/a/388334/30946
Matt avatar
lá cờ in
Nếu docker daemon đang chạy dưới dạng `root`, thì việc người dùng nào đang chạy các lệnh `docker` không thành vấn đề. Về cơ bản, người dùng có quyền truy cập root thông qua trình nền thực hiện công việc.
Matt avatar
lá cờ in
@OscarAndersson Không, bất kỳ người dùng nào trong nhóm `docker`, trong khi docker daemon đang chạy với quyền root, đều có quyền truy cập root vào máy và có thể kiểm soát các vùng chứa khác
Nonny Moose avatar
lá cờ gb
Cũng lưu ý rằng bạn có thể chuyển tiếp cổng docker sang một cổng đặc quyền.
Oscar Andersson avatar
lá cờ jp
Cảm ơn @NonnyMoose, đó là điều tôi đang làm. :)
Oscar Andersson avatar
lá cờ jp
Cảm ơn @MirceaVutcovici nghe có vẻ thú vị, tôi sẽ xem xét nó. :)
Oscar Andersson avatar
lá cờ jp
Vâng @Matt đó là một điểm thực sự tốt.Tôi không quá lo lắng về việc người dùng của mình cố tình phá vỡ hệ thống, điều quan trọng hơn là một số người trong số họ thiếu kinh nghiệm với hệ thống Linux và có thể tạo ra lỗ hổng bảo mật cho tin tặc. Tôi sẽ đưa ý kiến ​​​​của bạn vào tài khoản.
Điểm:3
lá cờ in

Các tên miền phụ được đảo ngược proxy bằng cách sử dụng nginx tới một cổng cụ thể.

Bạn có thể ủy quyền tên miền phụ cho ổ cắm Unix.

    proxy_pass http://unix:/var/run/anna.sock:/;

Lặp lại nếu cần cho từng tên miền phụ và đặt quyền trên các ổ cắm Unix để chỉ những người dùng bạn muốn mới có thể nghe ở đó.

Cũng lưu ý rằng người dùng có thể chạy bộ chứa Docker có thể gắn kết /etc/passwd vào chúng và giành được quyền root, vì vậy chúng phải được bảo vệ chống lại một cách riêng biệt.

Matt avatar
lá cờ in
Ý tưởng hay, nhưng tương tự như điểm thứ hai của bạn, docker cũng có thể gắn bất kỳ ổ cắm nào trừ khi bạn thêm một số hình thức kiểm soát khác đối với những gì người dùng có thể chạy qua docker.
Oscar Andersson avatar
lá cờ jp
Koterpillar và @matt, tôi có thể liên kết/xuất bản docker máng ổ cắm unix hay tôi nên sử dụng cổng cho việc này? Đọc điều gì đó về việc nó chưa được hỗ trợ đầy đủ bởi docker.
Oscar Andersson avatar
lá cờ jp
Cảm ơn Koterpillar đã đề cập đến ý nghĩa bảo mật của việc cấp cho người dùng quyền truy cập docker.
lá cờ in
Vì ổ cắm UNIX là một tệp, hãy thử gắn nó vào vùng chứa.
Điểm:1
lá cờ pk

Chỉ muốn thêm một góc nhìn khác...chắc chắn còn nhiều việc phải làm! Nhưng thú vị...

Cân nhắc việc chạy một bộ điều phối vùng chứa, chẳng hạn như Kubernetes. Thủ tục thanh toán KIND (Kubernetes-in-Docker) để biết một cách thú vị để chạy cụm Kubernetes trên một nút duy nhất chỉ với Docker.

Sau đó, bạn có thể, ví dụ, làm điều gì đó như

Nếu bạn cấu trúc đúng vai trò, người dùng có thể được phép khởi chạy bất kỳ vùng chứa nào họ muốn trong không gian tên của họ, nhưng sẽ không được phép sửa đổi dịch vụ trong đó xác định các cổng tiếp xúc.

Điều này được đơn giản hóa vì lợi ích của không gian, nhưng những thứ nguyên thủy mà thứ gì đó như k8 cung cấp là tuyệt vời cho các hệ thống nhiều người thuê như thế này.

Oscar Andersson avatar
lá cờ jp
Cảm ơn Budris, bài đăng của bạn thực sự truyền cảm hứng và một chút thử nghiệm nếu tôi có thể nói như vậy. Tôi tin rằng nó hơi quá phức tạp đối với tôi. Cảm ơn.
Mr.Budris avatar
lá cờ pk
vâng, một cái gì đó như kubernetes có thể là quá mức cần thiết cho môi trường của bạn, nhưng hãy ghi nhớ những hệ thống như thế này nếu phòng thí nghiệm của bạn phát triển -- có thể giúp bạn tiết kiệm rất nhiều thời gian (và là một trải nghiệm học tập thú vị) cho tương lai. Chúc mừng!
Oscar Andersson avatar
lá cờ jp
Cảm ơn, tôi chắc chắn tham gia để có kinh nghiệm học tập. :) (Btw đã giải quyết vấn đề của tôi với docker không root, hệ thống kéo dài ở cấp độ người dùng và người dùng không root thông thường trên máy chủ)

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.