Điểm:0

Làm cách nào tôi có thể nhận được đường dẫn hợp lệ từ đối số trong tập lệnh #!/bin/sh?

lá cờ cn

Tôi có một số tập lệnh (bản sao) và muốn nhận đường dẫn hợp lệ.

#!/bin/sh
cp -R $1 $2

Tôi đã thử với tham số như thế này

./copy.sh /home/apple /home/pie;reboot

sau đó máy chủ đã được khởi động lại và nó không được chấp nhận trong máy chủ sản xuất.

Tôi biết đường dẫn linux chỉ được tạo với [a-zA-Z0-9_-/. ]

Làm cách nào tôi có thể lọc $1 và $2 để tôi có thể gọi mà không cần lo lắng.

#!/bin/sh
$filtered_path_1=some_filter_funtion($1)
$filtered_path_2=some_filter_function($2)
cp -R $filtered_path_1 $filtered_path_2

Lý lịch

Tôi có jenkinsfile và gọi sh 'sudo /home/copy.sh ${Workspace} ${targetdir}' trong tệp jenkins này. Vì người dùng jenkins không có quyền ghi trên ${targetdir}, nên tôi chỉ cấp quyền root cho người dùng jenkins trên tập lệnh copy.sh này qua

sudo visudo jenkins    
TẤT CẢ = NOPASSWD: /home/copy.sh, 

Và jenkinsfile này nằm trong kho git. Nếu kẻ xấu sửa đổi tệp jenkins này bằng mã xấu như khởi động lại và thực hiện nó, thì tập lệnh sao chép sẽ được gọi tự động. Bởi vì tập lệnh này được gọi trong quyền root, anh ta có thể làm những điều xấu bằng cách sử dụng điểm yếu này. Anh ấy sẽ xóa sh 'sudo /home/copy.sh ${Workspace} ${targetdir}' và sẽ thêm sh 'sudo /home/copy.sh /tmp /var;reboot'.

Làm thế nào tôi có thể bảo vệ anh ấy?

lá cờ cn
Dán mã của bạn vào https://www.shellcheck.net để được tư vấn giải quyết vấn đề này.
Denis Turgenev avatar
lá cờ cn
@glenn, cảm ơn bạn và tôi nghĩ nó không đưa ra giải pháp về cách thay đổi $1->$safe1.
lá cờ ru
@DenisTurgenev Không liên quan gì đến việc phân tích cú pháp đối số để làm cho nó an toàn. Nó có mọi thứ liên quan đến môi trường shell mà bạn đang thực thi theo mặc định (tức là bash). Câu trả lời của tôi chi tiết toàn bộ điều này. Và cung cấp cho bạn tập lệnh thử nghiệm và bộ lệnh cho bạn thấy điều này đang hoạt động mà không làm nổ hệ thống của bạn
bac0n avatar
lá cờ cn
`./copy.sh evil.sh copy.sh` rất tiếc
Điểm:2
lá cờ ru

Điều này không có gì để làm với kịch bản của bạn. Trong vỏ Bash, ; được xem như lệnh kết thúc chuỗi lệnh, rồi ngay sau nó là lệnh phụ. Vì vậy, trên thực tế, cách xử lý nội dung của bạn như sau.

  1. Thực hiện lệnh trước khi ;:

    ./copycron.sh /home/apple /home/pie
    
  2. Thực hiện lệnh thứ hai sau lệnh ;:

     khởi động lại
    

Bởi vì bạn đã thực hiện có khả năng như nguồn gốc hoặc siêu người dùng, nó đã khởi động lại thành công.

Tuy nhiên, nếu bạn làm điều gì đó cụ thể hơn và thực hiện một lệnh tùy ý khác sau ; thay vào đó, bạn sẽ nhận thấy lệnh đó được chạy. Hai đối số của bạn cho kịch bản của bạn sẽ vẫn còn /nhà/quả táo/nhà/bánh tương ứng. Kịch bản không bao giờ nhìn thấy ;khởi động lại một phần vì điều đó không được phân tích cú pháp dưới dạng đối số. Đây là giới hạn của Bash chứ không phải thứ gì đó trong tập lệnh của bạn.


Bạn có thể kiểm tra điều này bằng tập lệnh sau và sau đó gọi lệnh:

TẬP TIN: argecho.sh

#!/bin/bash

echo "Đối số được phân tách bằng dấu cách: $*"
tiếng vang ""
tiếng vang "------"
tiếng vang ""

LỆNH ĐỂ THỰC HIỆN: ./argecho.sh foo bar baz /tmp/something.txt;echo Tôi đã làm việc khác

ĐẦU RA:

$ ./argecho.sh foo bar baz /tmp/something.txt;echo Tôi đã làm điều gì đó khác bên ngoài tập lệnh, thấy không?
Các đối số được phân tách bằng dấu cách: foo bar baz /tmp/something.txt

------

Tôi đã làm điều gì đó khác ngoài kịch bản, thấy không?

Bạn sẽ nhận thấy 'tiếng vang' và các đối số khác trong đó không được đưa vào các đối số trong tập lệnh của bạn. Đây là hành vi Bash tiêu chuẩn.



Dựa trên các chỉnh sửa của bạn, mối lo ngại của bạn là ai đó sẽ chiếm quyền điều khiển các lệnh trong kho lưu trữ Jenkins của bạn và đưa ra một lệnh độc hại, bằng cách thay đổi tập lệnh từ sh 'copycron "${Workspace}" "${targetdir}"' đến sh copycron /home /boot; tắt máy

Thật không may cho bạn, điều này hoàn toàn không có gì bạn có thể sửa chữa, điều này sẽ dẫn đến việc bạn không thể kiểm soát đúng cách những người có quyền truy cập vào kho lưu trữ lệnh. Những kẻ đe dọa như vậy sẽ có nhiều quyền truy cập hơn để làm hỏng hệ thống của bạn, không chỉ chạy một lệnh đơn giản như những thay đổi đã nói ở trên. Họ có nhiều khả năng sẽ cài đặt phần mềm độc hại trên hệ thống của bạn hơn bất cứ thứ gì và trừ khi bạn bảo mật đúng cách các kho lưu trữ lệnh của mình để không ai có thể 'chỉnh sửa chúng một cách ngẫu nhiên', nếu không việc bạn không kiểm soát được các kho lưu trữ sẽ khiến bạn gặp rắc rối.

Chúng ta không thể làm gì khó hơn ở đây nếu người dùng jenkins cũng có đặc quyền sudo không giới hạn. Đơn giản là không, bởi vì điều này sẽ phụ thuộc vào việc bạn bảo mật hệ thống của mình đúng cách hay xây dựng một cơ chế triển khai thay thế an toàn hơn và không yêu cầu đầy đủ sudo để làm việc với mọi thứ.

Denis Turgenev avatar
lá cờ cn
Tôi có jenkinsfile và gọi `sh 'copycron ${Workspace} ${targetdir}'` trong jenkinsfile. Và jenkinsfile này nằm trong kho git. Người dùng jenkins chỉ có quyền root trên tập lệnh copycron này thông qua `sudo visudo jenkins ALL = NOPASSWD: /home/copycron`, vì jenkins không có quyền ghi vào ${targetdir} và nếu kẻ xấu sửa đổi tệp jenkins này bằng mã xấu như khởi động lại và thực hiện nó, thì các tập lệnh copycron sẽ được gọi tự động và bởi vì tập lệnh này được gọi trong đặc quyền gốc, anh ta có thể làm điều xấu.
lá cờ ru
Đây là giới hạn cuộc gọi của bạn thông qua `sh` chứ không phải giới hạn của mọi thứ khác hoặc thậm chí là tập lệnh của bạn. Vấn đề là `sh` thực thi điều này trong shell giống như khi tôi thực thi nó trong Bash. Bạn nên đặt các trích dẫn đầy đủ xung quanh các đối số của mình nếu bạn muốn nó 'khử trùng' và không chạy nó. I E.`sh 'copycron "${Workspace}" "${targetdir}"'` Bằng cách đó, nó xử lý ; như một phần của chuỗi. Sau đó, tập lệnh của bạn sẽ bị lỗi vì không thể tìm thấy targetdir.
Denis Turgenev avatar
lá cờ cn
Vấn đề là kẻ xấu có thể thay đổi kịch bản chi tiết của tôi một cách dễ dàng. `sh 'copycron "${Workspace}" "${targetdir}"'` -> `sh copycron /home /boot;shutdown` Vì tệp jenkins nằm trong kho lưu trữ git.
lá cờ ru
@DenisTugenev Tôi nghĩ rằng tôi phải hỏi một câu hỏi khác: tại sao bạn lại lo ngại rằng 'kẻ xấu' có liên quan? Nếu kho lưu trữ được bảo mật đúng cách, kẻ xấu sẽ không có quyền truy cập để chỉnh sửa tập lệnh. Nếu kẻ xấu * giành được * quyền truy cập vào tập lệnh, thì bạn cũng sẽ bị lừa, không có cách nào để làm sạch lệnh mà bạn đang chỉ định. Đó là lỗi không thể kiểm soát các kho lưu trữ của bạn, không phải là sự cố tập lệnh Bash và *không phải* thứ gì đó mà bạn có thể bảo vệ chống lại nếu bạn không bảo mật đúng cách các kho lưu trữ lệnh của mình.
Denis Turgenev avatar
lá cờ cn
Nhân tiện, bạn gọi kẻ xấu như vậy trong thuật ngữ bảo mật là gì? :) Tôi không phải là chuyên gia bảo mật và cũng không phải chuyên gia tiếng Anh.
Denis Turgenev avatar
lá cờ cn
Đây là dự án được phát triển bởi 50 nhà phát triển và tất nhiên chỉ những người này mới có thể truy cập bằng tài khoản của họ. Ví dụ: một nhà phát triển đã bị sa thải và khi anh ta rời công ty, anh ta nói 'đi chết đi!', và có thể thực hiện điều này. Nhưng đây có phải là giả định quá khắc nghiệt? :) Tôi thích tưởng tượng vô cùng, vì vậy hãy tha thứ cho tôi nếu tôi quá khắt khe.
lá cờ ru
Đây là một cuộc thảo luận lớn hơn so với các bình luận có thể thực hiện và sẽ bắt đầu yêu cầu chiếc mũ bảo mật của tôi đưa ra lời giải thích chính xác về vấn đề "mối đe dọa nội bộ" và quản lý người dùng không phù hợp cũng như kiểm tra không phù hợp từ phía bạn. Nếu bạn muốn trò chuyện đó, tôi có thể tạo một phòng trò chuyện để bạn và tôi thảo luận sâu về vấn đề này, tuy nhiên, đó là một vấn đề sâu hơn nhiều so với những gì có thể thảo luận trong phần nhận xét.
Denis Turgenev avatar
lá cờ cn
cảm ơn, tôi sẽ thu thập thêm một số vấn đề bảo mật và sẽ sớm liên hệ với bạn. cảm ơn vì thời gian và sự giúp đỡ quý báu của bạn.

Đă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.