Tôi đang thử nghiệm các khả năng, trên Debian Gnu / Linux.

Tôi đã sao chép / bin / ping vào thư mục làm việc hiện tại của tôi. Như mong đợi, nó không hoạt động, ban đầu nó được cài đặt gốc.

Sau đó, tôi cung cấp cho ping của mình các khả năng tối thiểu (không phải root) bằng cách thực hiện sudo /sbin/setcap cap_net_raw=ep ./pingvà ping của tôi hoạt động, như mong đợi.

Sau đó sudo /sbin/setcap -r ./pingđể thu hồi khả năng đó. Bây giờ nó không hoạt động như mong đợi.

Bây giờ tôi cố gắng để ping làm việc bằng cách sử dụng capsh.

capsh không có đặc quyền, vì vậy tôi cần chạy nó dưới quyền root, nhưng sau đó thả root và do đó tất cả các đặc quyền khác.

Tôi nghĩ rằng tôi cũng cần secure-keep-caps, điều này không được ghi lại trong tài liệu capshhướng dẫn. Tôi đã nhận được số bit từ /usr/include/linux/securebits.h. Chúng có vẻ đúng, vì đầu ra của --printcác bit này là chính xác.

Tôi đã nghịch ngợm trong nhiều giờ, cho đến nay tôi có điều này.

sudo /sbin/capsh --keep=1 --secbits=0x10 --caps="cap_net_raw+epi" == --secbits=0x10 --user=${USER} --print -- -c "./ping localhost"

Tuy nhiên, pinglỗi với ping: icmp open socket: Operation not permitted, đây là những gì xảy ra khi nó không có khả năng. Ngoài ra các --printchương trình Current: =p cap_net_raw+i, điều này là không đủ chúng ta cần e.

sudo /sbin/capsh --caps="cap_net_raw+epi" --print -- -c "./ping localhost"sẽ thiết lập khả năng Current: = cap_net_raw+eipnày là chính xác, nhưng để lại cho chúng tôi root.

Chỉnh sửa-1

Bây giờ tôi đã thử sudo /sbin/capsh --keep=1 --secbits=0x11 --caps=cap_net_raw+epi --print -- -c "touch zz; ./ping -c1 localhost;"

Điều này tạo ra:

touch: cannot touch `zz': Permission denied
ping: icmp open socket: Operation not permitted

Lỗi đầu tiên được dự kiến ​​là secure-noroot: yes Nhưng thứ hai thì khôngCurrent: = cap_net_raw+eip

Chỉnh sửa-2

Nếu tôi đặt ==trước --print, bây giờ nó sẽ hiển thị Current: = cap_net_raw+i, để giải thích lỗi trước đó, nhưng không hiểu tại sao chúng tôi mất khả năng khi chuyển khỏi root, tôi mặc dù điều đó secure-keep-capssẽ khắc phục điều đó.

Chỉnh sửa-3

Từ những gì tôi có thể thấy, tôi mất hiệu quả (e) và Được phép (p), khi exec được gọi. Điều này được mong đợi, nhưng tôi nghĩ rằng việc giữ an toàn, sẽ ngăn chặn chúng bị mất. Tui bỏ lỡ điều gì vậy.

Chỉnh sửa-4

Tôi đã làm nhiều nghiên cứu hơn, và đọc lại hướng dẫn. Dường như bình thường evà các pkhả năng bị mất khi: bạn chuyển từ người dùng root(hoặc áp dụng secure-noroot, do đó làm cho root trở thành người dùng bình thường), điều này có thể bị ghi đè secure-keep-caps; Khi bạn gọi exec, theo như tôi có thể nói đây là một bất biến.

Theo như tôi có thể nói, nó đang hoạt động theo hướng dẫn. Theo như tôi có thể nói không có cách nào để làm bất cứ điều gì hữu ích với capsh. Theo như tôi có thể nói, để sử dụng các khả năng bạn cần: sử dụng khả năng của tệp hoặc có chương trình nhận biết khả năng, điều đó không sử dụng exec. Do đó không có đặc quyền bao bọc.

Vì vậy, bây giờ câu hỏi của tôi là tôi đang thiếu gì, để làm gì capsh.

Chỉnh sửa-5

Tôi đã thêm một câu trả lời khả năng xung quanh. Có capshthể cũng có thể được sử dụng với các khả năng được kế thừa, nhưng để hữu ích, những thứ này cần phải được đặt trên tệp thực thi. Tôi không thể thấy làm thế nào capsh có thể làm bất cứ điều gì hữu ích mà không có khả năng xung quanh hoặc để cho phép các khả năng được kế thừa.

Phiên bản:

• capshtừ libcap2-binphiên bản gói1:2.22-1.2
• trước khi chỉnh sửa-3 Tôi đã lấy bản mới nhất capshtừ git://git.debian.org/collab-maint/libcap2.gitvà bắt đầu sử dụng nó.
• uname -a Linux richard-laptop 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux Đất người dùng là 32 bit.

Khả năng là thuộc tính của các quá trình. Theo truyền thống có ba bộ:

• Các khả năng được phép ( p ): các khả năng có thể được "kích hoạt" trong quy trình hiện tại.
• Khả năng hiệu quả ( e ): các khả năng hiện có thể sử dụng được trong quy trình hiện tại.
• Khả năng kế thừa ( i ): khả năng tệp có thể được kế thừa.

Các chương trình chạy như root luôn có đầy đủ các khả năng được phép và hiệu quả, do đó, việc "thêm" nhiều khả năng hơn không có hiệu quả rõ rệt. (Bộ khả năng kế thừa thường trống.) Với setcap cap_net_raw+ep pingbạn bật các khả năng này theo mặc định cho bất kỳ người dùng nào chạy chương trình này.

Thật không may, các khả năng này bị ràng buộc với tệp được thực thi và không được giữ lại sau khi thực hiện một quy trình con mới. Linux 4.3 đã giới thiệu các khả năng Ambient cho phép các khả năng được kế thừa bởi các tiến trình con. (Xem thêm Chuyển đổi các khả năng trong khi thực hiện () trong các khả năng (7) .)

Trong khi chơi với các khả năng, lưu ý những cạm bẫy sau:

• Khi thay đổi người dùng từ root sang không root, các khả năng hiệu quả và được phép sẽ bị xóa (xem Hiệu ứng thay đổi ID người dùng đối với các khả năng trong các khả năng (7) ). Bạn có thể sử dụng --keep=1tùy chọn capshđể tránh xóa các bộ.
• Bộ khả năng xung quanh bị xóa khi thay đổi ID người dùng hoặc nhóm. Giải pháp: thêm các khả năng xung quanh sau khi thay đổi ID người dùng, nhưng trước khi thực hiện quy trình con.
• Một khả năng chỉ có thể được thêm vào bộ khả năng xung quanh nếu nó đã có trong cả bộ khả năng được phép và khả năng kế thừa.

Các capshchương trình từ libcap 2.25 không có khả năng sửa đổi khả năng môi trường xung quanh, nhưng các phiên bản sau này thêm tùy chọn mới. Lưu ý rằng thứ tự tùy chọn là đáng kể. Ví dụ sử dụng:

sudo capsh --caps="cap_net_raw+eip cap_setpcap,cap_setuid,cap_setgid+ep" \
    --keep=1 --user=nobody --addamb=cap_net_raw -- \
    -c "./ping -c1 127.0.0.1"

Mẹo: bạn có thể thêm --printtùy chọn ở bất cứ đâu trong capshdòng lệnh và xem trạng thái khả năng hiện tại của nó.

Lưu ý: cap_setpcaplà cần thiết --addambtrong khi cap_setuid,cap_setgidcần thiết cho --usertùy chọn.

Câu trả lời của Lekensteyn có vẻ chính xác và đầy đủ nhưng tôi sẽ cố gắng đưa ra một lời giải thích khác từ một góc độ khác sẽ cố gắng nhấn mạnh vấn đề mà các khả năng xung quanh đặt ra.

Khi bạn chạy sudo capsh --user=<some_user> --Có 2 cuộc gọi hệ thống quan tâm khiến các khả năng được tính toán lại (và có khả năng bị loại bỏ):

1. setuid: Theo man capabilities:

SECBIT_KEEP_CAPS Đặt cờ này cho phép một luồng có một hoặc nhiều UID giữ lại các khả năng của nó khi nó chuyển tất cả các UID của nó thành giá trị khác không. Nếu cờ này không được đặt, thì UIDswitch như vậy sẽ khiến luồng bị mất tất cả các khả năng.

Nói cách khác, trong capshlệnh của chúng tôi ở trên, chúng tôi cần đảm bảo rằng SECBIT_KEEP_CAPS được đặt trong khi setuidgọi hệ thống. Nếu không, tất cả các khả năng bị mất. Đây là những gì --keep=1làm. Vì vậy, bây giờ lệnh trở thànhsudo capsh --user=<some_user> --keep=1 --

2. execve: Nếu chúng ta sử dụng các --keep=1tùy chọn, tất cả các bộ khả năng (có hiệu lực, cho phép, thừa kế) được bảo toàn cho đến khi các execvecuộc gọi hệ thống, tuy nhiên execvenguyên nhân khả năng được tính toán lại (cho người dùng không root) là tốt, và theo một cách không rõ ràng. Nói tóm lại, trước khi bổ sung bộ khả năng xung quanh , để khả năng nằm trong bộ "được phép" của một luồng sau một execvecuộc gọi, một trong hai:

   • Tệp phải có khả năng đó trong bộ "được phép" . Điều này có thể được thực hiện với setcap cap_net_raw+p /bin/bash. Làm điều này làm cho toàn bộ bài tập trở nên vô dụng vì các bộ khả năng của luồng (trừ bộ giới hạn) không còn có tác dụng.
   • Cả tệp và luồng phải có khả năng đó trong các tập hợp "kế thừa" của chúng . Bạn có thể nghĩ rằng điều đó setcap cap_net_raw+isẽ tạo ra mánh khóe nhưng hóa ra điều đó execvekhiến cho các quyền có thể thừa kế của một chuỗi bị bỏ khi được gọi bởi một người dùng không có đặc quyền (mà chúng tôi hiện đang nhờ setuid). Vì vậy, không có cách nào để đáp ứng điều kiện này như một người dùng không có quyền.

Các khả năng xung quanh được giới thiệu trong Linux 4.3 giúp cho một luồng có thể giữ được các khả năng của nó ngay cả sau khi một setuidngười dùng không có đặc quyền theo sau execve, mà không phải phụ thuộc vào các khả năng của tệp.

Có thể có một lỗi / tính năng trong kernel. Đã có một số cuộc thảo luận:

• https://ormszilla.altlinux.org/show_orms.cgi?id=16694
• http://linux.derkeiler.com/Mending-Lists/Kernel/2005-03/5224.html

Tôi không có ý tưởng, nếu bất cứ điều gì đã được thực hiện, để sửa chữa nó.

Đừng hiểu lầm tôi - hành vi hiện tại là an toàn. Nhưng nó an toàn đến nỗi nó cản trở mọi thứ sẽ hoạt động.

Chỉnh sửa: Theo http://man7.org/linux/man-pages/man7/capabilities.7.html có một bộ khả năng mới Ambient (kể từ Linux 4.3). Có vẻ như điều này sẽ cho phép những gì cần thiết.