Vet – Công cụ thực thi script shell từ xa an toàn hơn

 (getvet.sh)
10 điểm bởi GN⁺ 2025-07-02 | 1 bình luận | Chia sẻ qua WhatsApp
  • vet là một công cụ CLI giúp chuyển việc chạy script cài đặt từ xa theo kiểu curl | bash sang quy trình an toàn "tải xuống → xem xét → phê duyệt để chạy"
  • Cung cấp các lớp phòng vệ theo từng bước như xem lịch sử thay đổi (diff) của script, lint (phân tích tĩnh) dựa trên shellcheck, và phê duyệt thủ công (xác nhận rồi mới chạy)
  • Chỉ với một lệnh duy nhất (vet https://example.com/install.sh), có thể tự động kiểm tra rủi ro tiềm ẩn, giả mạo, lỗi gõ và lỗ hổng trước khi thực thi script từ xa
  • Bản thân việc cài đặt cũng hỗ trợ cả cách "tải xuống rồi xem xét" lẫn cách curl | sh, và mã cài đặt của chính vet cũng có thể được kiểm tra trực tiếp
  • Đây là một giải pháp đáng tin cậy giúp đồng thời đảm bảo phòng ngừa rủi ro bảo mật trong môi trường phát triển/vận hành và tính tự động hóa/sự tiện lợi

Vấn đề: thực thi bừa bãi các script cài đặt từ xa

  • Nhiều dự án mã nguồn mở và công cụ hướng dẫn cài đặt bằng script từ xa như curl -sSL https://example.com/install.sh | bash
  • Cách này tiềm ẩn rủi ro bảo mật nghiêm trọng như thực thi mã độc, chạy file chưa tải hoàn chỉnh do script bị chỉnh sửa, máy chủ bị xâm nhập hoặc lỗi mạng

Giải pháp của vet: thực thi tương tác an toàn

  • vet bao bọc việc thực thi script từ xa bằng quy trình bảo mật 4 bước như sau
    • 1. Fetch: tải script từ xa về vị trí tạm một cách an toàn
    • 2. Diff & Review: so sánh với lịch sử chạy trước đó để hiển thị thay đổi (diff), tự mình xem xét trực quan phần mã mới/thay đổi
    • 3. Lint: dùng shellcheck (khi đã cài đặt) để tự động phân tích tĩnh lỗi, lỗ hổng và các mẫu bất thường
    • 4. Confirm: trước khi chạy thật, yêu cầu người dùng nhập phê duyệt cuối cùng (yes/no)
  • Lệnh duy nhất: 
    vet https://example.com/install.sh

Cách cài đặt

Cách khuyến nghị an toàn (tải xuống → xem xét → thực thi)

Cài đặt nhanh (one-line dựa trên mức độ tin cậy)

Tính năng và ưu điểm của vet

  • Phát hiện thay đổi (diff): có thể kiểm tra phần vừa thay đổi bằng cách so sánh với script đã chạy trước đó
  • Lint tự động (tích hợp shellcheck): tự động chẩn đoán lỗ hổng, lỗi gõ và mã đáng ngờ trong shell script
  • Phê duyệt thực thi tường minh (Confirm): trực tiếp kiểm soát việc chạy thực tế chỉ bằng một lần nhấp/nhập
  • Tự động lưu script và quản lý lịch sử: ngay cả các script cài đặt dùng thường xuyên cũng có thể được theo dõi an toàn
  • Đảm bảo cài đặt/cập nhật an toàn ngay ở bên trong

Kết luận

  • vet là giải pháp thay thế an toàn cho curl | bash mà cả lập trình viên lẫn người vận hành đều cần, hiện thực hóa cả tự động hóa cài đặt lẫn bảo mật
  • "Đừng chỉ chạy ngay, hãy xác minh bằng vet rồi mới thực thi!"

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-07-02
Ý kiến trên Hacker News
  • Trong 90% trường hợp, tôi tự hỏi thực tế mọi người xác minh độ tin cậy của phần mềm như thế nào khi dùng trình cài đặt. Ở một số trường hợp có ký mã, nhưng nhiều trường hợp mã được tải xuống từ cùng máy chủ HTTPS mà không có xác minh bổ sung. Nếu mã ở dạng đã biên dịch thì cũng muốn hỏi liệu có ai diff hay không. Việc cứ thế chạy trình cài đặt từ Internet không phải cách hay, và nếu cài từ bản phân phối của hệ điều hành thì có các cơ chế xác minh tốt hơn nhiều. Dù vậy, những cách này cũng không giúp tăng niềm tin lên đáng kể
    • Mục tiêu của vet là tập trung vào bảo mật của chính script cài đặt, đặc biệt là ngăn script cài đặt bị sửa để bỏ qua bước xác minh checksum hoặc tải binary từ URL độc hại. Ở một phần của chuỗi thì nó đóng vai trò bảo vệ mạnh, nhưng không bao quát toàn bộ chuỗi
    • Trình cài đặt thường chỉ chạy một lần, nên tôi băn khoăn việc hiển thị thay đổi so với lần chạy trước thực sự hữu ích đến mức nào
    • Tôi chỉ cài thông qua danh sách gói do cộng đồng quản lý, có ký mật mã và đáng tin cậy, dùng các phương thức có lịch sử bảo mật vững chắc. Tôi nghĩ vấn đề gốc không hẳn là bảo mật script tải xuống quá khó, mà là văn hóa chấp nhận kiểu cài đặt chắp vá này trong một số cộng đồng như macOS. Cần có yêu cầu mạnh hơn đối với các nền tảng đáng tin cậy. Tôi không nghĩ việc chạy lint trên shell script tải từ Internet sẽ làm bảo mật tốt hơn
  • Tôi tự hỏi điều gì sẽ xảy ra nếu ai đó liên tục chèn pragma # shellcheck disable= vào một script độc hại
    • Ý hay đấy. Đúng là có thể làm vậy. vet không chỉ tin vào ShellCheck, mà diff mới là cốt lõi. Dù linter im lặng, diff vẫn có thể phát hiện việc chèn đoạn # shellcheck disable= đáng ngại. Bản thân thay đổi đó đã là tín hiệu cảnh báo
  • Có cảm giác khá mỉa mai: 
    # Tình huống mù quáng tin vào script từ xa:
curl -sSL https://example.com/install.sh | bash
    rồi tiếp theo lại chạy 
    curl -sL https://getvet.sh | sh
    • Có lẽ tôi đã lướt qua mà không đọc đoạn đó. Điểm cốt lõi của vet là nó nhận thức được chính sự mỉa mai ấy. Nó khuyến khích người dùng tự kiểm tra script cài đặt của vet. Đó chính là mục tiêu của vet. Bạn có thể xem trực tiếp mã nguồn của install.sh
  • Tôi nghĩ đây là một giải pháp rất hay. Tôi cũng hay băn khoăn chuyện này, và với uv chẳng hạn tôi cũng từng thắc mắc. Nhưng trong đa số trường hợp, mọi người đều tin người quản lý mã nên chấp nhận dùng như một sự thỏa hiệp
    • Tôi tò mò bạn nghĩ gì về uv
  • Cuộc thảo luận này khiến tôi nghĩ bước tiếp theo của vet nên là hỗ trợ môi trường riêng tư. Xác minh script công khai thì tốt, nhưng rồi cũng cần chạy script triển khai từ GitHub repo nội bộ hoặc máy chủ nội bộ. Vì vậy tôi đã mở một yêu cầu tính năng để thêm xác thực vào vet. Hỗ trợ .netrc, biến môi trường VET_TOKEN, và về sau còn đưa vào lộ trình tích hợp với secret manager như HashiCorp Vault. Nếu quan tâm, tôi muốn nghe ý kiến trong GitHub issue. Cảm ơn phản hồi
  • Tôi muốn hỏi liệu trên trang hay trong readme có thể cho thấy cách nó hoạt động hoặc video demo không. Nó mở bằng pager hay editor, cảnh báo của shellcheck được hiển thị ra sao
    • Chuẩn đấy. README hiện chỉ nói về cách vet hoạt động, chứ chưa cho thấy rõ trải nghiệm dùng thực tế. Tôi định thêm GIF demo vào trang. Trả lời câu hỏi thì mặc định nó mở tệp bằng pager (less, hoặc nếu cài bat thì dùng pager có tô sáng đẹp hơn), và không mở bằng editor để tránh sửa nhầm. Nếu ShellCheck phát hiện vấn đề, nó sẽ in màu trực tiếp ra terminal. Sau đó nó sẽ hỏi rõ có tiếp tục review hay không theo dạng [y/N]. Ví dụ: 
      ==> Running ShellCheck analysis...

In /tmp/tmp.XXXXXX line 7:
echo "Processing file: $filename"
           ^-- SC2086: Double quote to prevent globbing and word splitting.

==> WARNING: ShellCheck found potential issues.
[?] Continue with review despite issues? [y/N]
      Cảm ơn gợi ý hay
  • Hơi tiếc là nó không chạy tự động như mẫu curl | bash. Trên Windows có tính năng tự động quét tệp khi người dùng định cài đặt
  • Ý tưởng quá hay. Thách thức lớn nhất của các công cụ bảo mật kiểu này là tính không quyết định của LLM và rủi ro riêng tư khi mã bị gửi tới API của bên thứ ba. Đó cũng là lý do vet dựa vào ShellCheck. ShellCheck là một linter có tính quyết định, dựa trên luật, chạy hoàn toàn offline. Cùng một đầu vào sẽ luôn cho ra kết quả đáng tin cậy như nhau. Để có phân tích thông minh hơn, tôi nghĩ về lâu dài vet sẽ cần AI chạy nhanh và cục bộ. Đây là một hướng suy nghĩ đáng giá
  • Ý tưởng thật sự rất sáng tạo. Một tính năng bổ sung thú vị có thể là gửi nội dung shell script cho LLM để tìm ra các phần đáng ngờ về bảo mật
  • Chào HN, tôi là tác giả của vet. Tôi luôn thấy mô thức curl | bash không yên tâm, và cảm thấy cần một công cụ có thể hiển thị diff khi script thay đổi, chạy shellcheck và yêu cầu người dùng cho phép rõ ràng. Vì vậy tôi tạo ra vet. Cách cài đặt cũng áp dụng cùng nguyên tắc đó. Tôi khuyến khích bạn nhất định nên đọc script cài đặt. Rất mong nhận được phản hồi. Repo ở https://github.com/vet-run/vet
    • Tôi mừng vì không chỉ mình tôi nghĩ về vấn đề này. Tôi cho rằng đây là điểm dễ bị tấn công kiểu khai thác lỗ hổng. Tôi thấy thú vị khi bạn lấy nvm làm ví dụ (trước đây tôi cũng từng nêu vấn đề tương tự với nvm). Tuy vậy, threat model hơi chưa rõ. Nếu một kẻ tấn công có thể can thiệp SSL và cung cấp script độc hại, thì tôi cho rằng hắn cũng đủ tinh vi để thay cả binary mà script thật tải xuống. Xác minh bằng hash mật mã tuy khó để mọi người duy trì, nhưng rốt cuộc vẫn là cách chắc chắn nhất. 1) Lấy đầu vào từ xa và so với hash đã commit 2) Chạy trong sandbox bị ngắt Internet 3) Chặn nhận payload nếu hash chưa được xác minh
    • Tôi muốn hỏi lý do của việc “hiển thị diff khi script thay đổi rồi chạy shellcheck” là gì. Bạn đã từng nghĩ vai trò của shellcheck thực sự là gì chưa, và bạn cho rằng khi nào diff sẽ phát huy tác dụng? “Yêu cầu cho phép rõ ràng trước khi chạy” cũng vô ích nếu thay đổi chỉ là chỉnh lại thụt lề. Script shell nhỏ thì đọc nhanh được, nhưng các trình cài đặt lớn thường dùng kiểu mã khó đọc vì nhiều lý do chính đáng. Tôi không rõ vet đang nói đến triết lý nào. Cách vet làm thực chất khá giống mô thức mà kẻ tấn công dùng để phát tán mã độc (ví dụ: nếu tải bằng wget -qO- https://getvet.sh thì máy chủ đang trả về text/html). Thay vào đó, tôi muốn khuyên nên lấy trực tiếp install.sh. Về yêu cầu phản hồi, đây là một mẹo bash theo kiểu “hãy làm thế này”: 
      check () {
  echo "> $BASH_COMMAND" >&2
  echo -n "Allow? (yes/no) " >&2
  select c in yes no
  do
    if [ "$c" = "yes" ]
    then break
    elif [ "$c" = "no" ]
    then return 1
    fi
  done
}

shopt -s extdebug
trap check DEBUG
      Cách này sẽ yêu cầu cho phép mỗi khi bash định thực thi điều gì đó. Với script dài thì có thể phiền, nên có thể tùy biến bằng danh sách trắng các lệnh được coi là an toàn hoặc thêm tùy chọn “remember”. Về sudo, mã độc có thể dùng thủ thuật chạy sudo trước trong một lệnh tưởng như vô hại để đưa thông tin xác thực vào cache, rồi sau đó gọi lại lệnh sudo mà không có cảnh báo nào. Sẽ an toàn hơn nếu chạy sudo -k để xóa cache phiên trước khi chạy chương trình chưa rõ nguồn gốc
    • Tôi đánh giá cao việc phát hiện ra vấn đề và cố gắng tạo giải pháp, nhưng vai trò vốn có của shellcheck không phải là quét virus/lỗ hổng, nên tôi thấy hướng đi của vet khó có hiệu quả lớn
    • Bản thân ý tưởng là tốt. vet sẽ hữu ích cho các lập trình viên khi mã nguồn được hiển thị rõ ràng và họ có thể tự đọc. Nhưng trình độ của tôi hiện chưa tới mức đó, nên tôi không rõ mình thuộc nhóm đa số người dùng hay thiểu số người dùng nữa