Lỗ hổng bảo mật nghiêm trọng trong Omarchy: Mọi tiến trình người dùng có thể leo thang lên quyền root
Omarchy, bản phân phối Linux mới của DHH, vừa vá một lỗ hổng bảo mật nghiêm trọng trong cấu hình Docker mặc định, cho phép mọi tiến trình trong phiên desktop của người dùng leo thang lên quyền root mà không cần mật khẩu. Lỗ hổng ảnh hưởng đến các phiên bản trước 4.0.1 và người dùng cần cập nhật ngay lập tức.
Lỗ hổng bảo mật nghiêm trọng trong Omarchy: Mọi tiến trình người dùng có thể leo thang lên quyền root
Omarchy, bản phân phối Linux tập trung vào phát triển phần mềm của DHH, vừa phải vá một lỗ hổng bảo mật nghiêm trọng trong cấu hình Docker mặc định. Lỗ hổng này cho phép về cơ bản mọi chương trình chạy trong phiên desktop của người dùng có thể leo thang lên quyền root mà không cần mật khẩu, sudo hay bất kỳ lời nhắc đặc quyền nào.
Nhà nghiên cứu bảo mật đã báo cáo vấn đề này qua quy trình tiết lộ có trách nhiệm của dự án. Cấu hình gây ra lỗ hổng đã được vá trong bản phát hành 4.0.1, và người dùng Omarchy cần cập nhật ngay lập tức.
Vấn đề nằm ở đâu?
Cấu hình mặc định của Omarchy thêm người dùng mặc định vào nhóm Linux docker. Điều này cho phép người dùng chạy các lệnh như docker run ... mà không cần gõ sudo.
Trên Arch Linux, daemon Docker chạy với quyền root và lắng nghe trên socket /var/run/docker.sock. Các thành viên của nhóm docker có thể giao tiếp với socket này. Docker cảnh báo rõ ràng rằng nhóm docker cấp cho người dùng các đặc quyền cấp root.
Một tiến trình có quyền truy cập vào Docker socket có thể yêu cầu daemon Docker (chạy với quyền root) khởi chạy container với quyền root, mount các phần tùy ý của hệ thống tệp máy chủ vào container, thao tác các tệp đó với quyền root và chạy mã với quyền root.
Trên các hệ thống Omarchy bị ảnh hưởng, điều này có nghĩa là người dùng mặc định và mọi tiến trình được khởi chạy trong phiên của người dùng đó đều có quyền truy cập root.
Bằng chứng khái niệm
Trên bản cài đặt Omarchy bị ảnh hưởng, thử đọc /etc/shadow:
$ cat /etc/shadow
cat: /etc/shadow: Permission denied
Bây giờ quan sát các nhóm của người dùng:
$ id
uid=1000(tester) gid=1000(tester) groups=1000(tester),967(docker),992(input),998(wheel)
Bây giờ đọc tệp được bảo vệ với Docker hoạt động như root:
$ docker run --rm -v /:/hostroot alpine cat /hostroot/etc/shadow
root:$6$...
bin:!*:...
daemon:!*:...
...
Lệnh được khởi chạy bởi một tiến trình người dùng bình thường, nhưng truy cập hệ thống tệp thực tế được thực hiện thông qua một daemon chạy với quyền root.
Phạm vi ảnh hưởng
Các nhóm bổ sung của Linux được kế thừa bởi các tiến trình con, vì vậy điều này ảnh hưởng đến toàn bộ phiên người dùng. Việc theo dõi cây tiến trình dưới phiên systemd --user cho thấy nhóm Docker hiện diện trên hầu hết mọi tiến trình bình thường trong phiên.
Điều này có nghĩa hầu hết mọi tiến trình có thể chạy mã không đáng tin cậy đều có thể trở thành root, bao gồm:
- Trình đại lý AI và khung công tác đại lý
- Trình duyệt web
- Trình soạn thảo và IDE
- Script npm
- Công cụ phát triển ngẫu nhiên
- Tiến trình nền
Nói cách khác, việc xâm phạm một ứng dụng người dùng bình thường có thể ngay lập tức trở thành xâm phạm toàn bộ máy.
Mặc định bảo mật sai lầm
Một khía cạnh quan trọng khác của cấu hình này là nó chọn bỏ qua (opt-out), không phải chọn tham gia (opt-in). Người dùng không cần phải thực sự sử dụng Docker. Sự đánh đổi bảo mật đã được thực hiện cho họ, áp dụng cho tài khoản mặc định, và sự đánh đổi đó không được giải thích cho người dùng.
Các mặc định nhạy cảm với bảo mật quan trọng chính vì nhiều người dùng hợp lý giả định rằng hệ điều hành mặc định là an toàn và sẽ thông báo hoặc nhắc họ tham gia vào các cài đặt kém an toàn hơn.
Tài liệu gây hiểu lầm
Omarchy có đề cập đến nhóm Docker trong tài liệu công cụ phát triển của mình:
Omarchy cài đặt mọi thứ cần thiết để chạy [docker] tốt. Điều này bao gồm [...] các thay đổi nhóm người dùng cần thiết để bạn chạy Docker như người dùng thông thường và không phải như root.
Hàm ý bảo mật gần như ngược lại với những gì người đọc thông thường có thể suy ra từ "không phải như root". Người dùng đọc mô tả đó có thể hợp lý kết luận rằng Omarchy đã cấu hình Docker ở một chế độ không root nào đó. Thực tế không phải vậy.
Phiên bản bị ảnh hưởng
Điều này ảnh hưởng đến các phiên bản trước 4.0.1. Nhà nghiên cứu đã kiểm tra trên ISO 3.x mới nhất (3.8.4) và nó cũng bị ảnh hưởng.
Dòng thời gian
Các commit từ khi giới thiệu đến khi giải quyết vấn đề:
- Ngày 1 tháng 6 năm 2025 — Giới thiệu thành viên nhóm Docker (commit
25799ee) - Ngày 2 tháng 6 năm 2025 — Tạm thời vô hiệu hóa thêm nhóm Docker (commit
c5ee230) - Ngày 17 tháng 6 năm 2025 — Kích hoạt lại thành viên nhóm Docker (commit
fdd2aaf) - Ngày 24 tháng 8 năm 2026 — Gỡ thành viên nhóm Docker khỏi cấu hình mặc định (commit
b5ded31)
Bối cảnh rộng hơn
Khi AI ngày càng tạo ra các CVE mức độ nghiêm trọng cao nhắm vào cơ sở hạ tầng cốt lõi, bảo mật cần được đặt lên hàng đầu đối với tất cả nhà phát triển, nhưng đặc biệt là các tác giả của bản phân phối nhắm vào nhà phát triển. Gần đây có vô số báo cáo về máy của nhà phát triển bị xâm phạm và quyền truy cập của họ được sử dụng để làm ô nhiễm chuỗi cung ứng phần mềm hoặc khai thác hệ thống sản xuất. Nhà phát triển là mục tiêu có giá trị cao vì mức độ truy cập mà họ thường được cấp.
Máy của nhà phát triển thường vô hiệu hóa các rào cản bảo mật để thuận tiện, lưu trữ thông tin xác thực trong các tệp dotfile dạng văn bản thuần túy, và tích lũy quyền truy cập vào các hệ thống. Điều này phải thay đổi.
Nhà nghiên cứu cho biết: "Tôi chắc chắn đây chỉ là sự sơ suất của DHH khi không biết hàm ý của việc thêm nhóm docker. Không có bản phân phối nào có thể đưa ra quyết định hoàn hảo khi nói đến bảo mật. Tôi rất ngạc nhiên về tốc độ phản hồi cho vấn đề này khi được báo cáo, đó là một dấu hiệu lành mạnh. Tuy nhiên, đây không phải lần đầu tiên tôi gặp phải vấn đề bảo mật với Omarchy và thẳng thắn mà nói, tôi không tin tưởng vào quy trình ra quyết định hiện tại để đảm bảo mức độ bảo mật mà tôi mong đợi từ bản phân phối của mình."
Đề xuất: Chuyển sang Podman
Nếu bạn là người dùng Docker trên Linux và không muốn bị buộc phải cấp root (ngay cả với sudo) để chạy container, hãy thử Podman. Podman không có daemon. Container của bạn chạy như các tiến trình con bình thường trong các user namespace riêng và không yêu cầu bất kỳ quyền root nào. Podman đã hoàn toàn thay thế mọi quy trình làm việc Docker.
Khuyến nghị cho người dùng Việt Nam
Với cộng đồng lập trình viên Việt Nam đang ngày càng quan tâm đến Omarchy, đây là lời nhắc nhở quan trọng:
- Cập nhật ngay lập tức lên Omarchy 4.0.1 hoặc mới hơn
- Nếu không thể cập nhật, hãy xóa người dùng của bạn khỏi nhóm
docker - Kiểm tra kỹ các bản phân phối mới trước khi sử dụng làm môi trường phát triển chính
- Luôn chạy các tác nhân AI trong môi trường cách ly (sandbox) nếu có thể