sudoers 파일이 답하는 질문은 하나입니다. 이 아이덴티티에 이 명령 패턴을 root로 실행할 권한이 있는가입니다. 명령의 실제 동작이나 위험도, 지금 실행하는 이유는 sudoers 항목만으로 따질 수 없습니다. 파일에 있는 계정인가와 이 명령을 한 번 더 확인해야 하는가는 서로 다른 질문입니다. sudoers는 앞의 질문만 다룹니다.
Alpacon은 sudo 권한을 아이덴티티에 상시 부여하지 않고 Work Session에 연결합니다. 사람 운영자와 AI 에이전트 모두에게 같은 방식으로 적용됩니다. AI 판단 티어를 활성화한 환경에서는 명령 API 경로로 들어온 sudo 요청을 권한 확인에 더해 규칙 레이어와 판단 레이어가 평가합니다. 이 글에서는 이 판단이 적용되는 범위와 적용되지 않는 경로를 함께 설명합니다.
상시 sudoers 권한이 맞지 않는 이유
전통적인 sudoers 항목은 파일에 있거나 없거나 둘 중 하나이며, 누군가 파일을 고칠 때까지 그대로 남습니다. 어떤 작업을 위해 권한을 받았는지 알지 못하고, 스스로 만료되지도 않습니다. 호출할 때마다 같은 규칙이 올바르게 작동한다고 전제할 뿐입니다.
CVE-2026-35535은 sudo 자체에 있던 권한 상승 취약점입니다. CVSS는 7.4이며, 로컬에서 높은 수준의 복잡성이 필요한 공격 경로입니다. sudo 1.9.17p2 이하 버전의 문제로, 3e474c2 커밋에서 패치됐습니다. sudo의 메일 알림 구성 요소를 실행하기 전에 setuid/setgid/setgroups로 권한을 낮추는 과정이 실패했는데도, 이를 치명적인 오류로 처리하지 않았습니다. 그 결과 sudo는 내려놨어야 할 상승 권한을 유지한 채 계속 실행됐습니다.
세션 경계로 이 취약점을 막을 수는 없었습니다. sudo 내부의 권한 하향 처리 경로에서 발생한 문제라 세션의 판단 범위보다 아래에 있기 때문입니다. sudo를 세션에 묶으면 매 호출에서 확인하는 질문은 달라집니다. sudoers 규칙은 이 아이덴티티가 이 패턴을 실행할 수 있는지만 판단합니다. AI 판단 티어를 켠 환경에서 명령 API를 거친 sudo 요청은 명령 자체의 위험도도 평가하고 결과를 매번 기록합니다. 상시 sudoers 권한은 구조상 이 두 번째 질문을 할 수 없습니다.
Work Session이 sudo 요청에 연결하는 정보
Alpacon의 실행 제어 레이어는 OS 수준 sudo와 Websh, 명령 API, MCP를 다룹니다. Work Session을 열 때는 아이덴티티와 작업 목적, 스코프를 반드시 선언합니다. AI 판단 티어가 켜져 있으면 명령 경로로 들어온 sudo 요청도 다른 명령처럼 세 단계 엔진에서 평가합니다. 승인자 카드에는 명령줄과 선언한 목적이 함께 표시됩니다. 이 티어가 꺼진 셀프 호스팅 기본 설정에서는 위험도 평가가 실행되지 않습니다. 명령 경로의 sudo는 sudoers와 마찬가지로 권한만 확인합니다. 적용되는 판단은 요청 경로와 AI 판단 티어의 활성화 여부에 따라 달라집니다.
예를 들어 명령 API를 쓰는 엔지니어나 에이전트가 web-03의 앱 티어를 재시작한다는 목적으로 세션을 열고, 해당 호스트에 sudo 스코프를 지정한다고 하겠습니다. 명령 허용 목록을 담은 별도 객체인 sudo 정책에서 systemctl을 허용했다면 sudo systemctl restart nginx는 추가 절차 없이 실행됩니다.
같은 세션에서 실행한 sudo cat /etc/shadow는 다릅니다. 이 명령은 허용 목록에 없으며, Alpacon 규칙 레이어의 40개 이상 패턴 중 자격증명 탈취에 바로 해당합니다. 리버스 셸, fork bomb, 디스크 삭제도 이 레이어가 다루는 패턴입니다. LLM 판단이나 승인자 개입 없이 규칙 레이어가 즉시 거부 판정을 계산합니다.
허용 목록이나 알려진 위험 패턴에 명확히 들어맞지 않는 명령은 즉시 허용하거나 거부하지 않습니다. 위험 점수 약 0.3~0.8의 회색 구간에서 LLM 판단 레이어를 거칩니다. 이 범위의 낮은 쪽에서는 사람이 참여 중인 세션은 자동 승인되고, 사람이 대신 책임질 수 없는 에이전트 모드 세션은 승인을 대기합니다. 높은 쪽에서는 두 모드 모두 기본적으로 사람의 승인을 기다립니다. 승인은 요청을 보낸 채널이 아닌 콘솔이나 Slack에서 이뤄집니다. 따라서 에이전트의 CLI나 서비스 토큰이 자신의 권한 상승을 승인할 수 없습니다. sudoers에는 없는 질문도 남습니다. 허용 목록 밖의 이 명령을 다시 검토해야 하는가입니다.
명령 API 경로의 sudo는 sudoers와 같은 권한 확인을 한 뒤, 명령이 실제로 무엇을 하는지 추가로 평가합니다. 그 판단이 실행 결과를 바꾸는지는 배포 설정에 달려 있습니다. Alpacon은 위험도 평가가 표시한 명령을 거부하거나 실행 전 승인을 대기시킬 수 있습니다. 하지만 현재 제공되는 기본 설정은 monitor-and-record입니다. 판단 결과는 매번 기록되지만, 배포 설정에 따라 실행에 반영되지 않을 수도 있습니다.
세션 모델이 적용되지 않는 sudo 경로
세션 모델 밖에 있는 경로도 있고, 모델 안에 있으면서 필요한 검사를 거치지 않는 경로도 하나 있습니다. 이 설명은 Alpacon이 관리하는 호스트를 전제로 합니다. 호스트에 통합 기능이 설치돼 있지 않거나 활성화돼 있지 않으면, sudo는 기존과 같이 로컬 규칙과 로컬 프롬프트만 따릅니다.
첫째, 아이덴티티에 연결되지 않은 시스템 계정입니다. 공유 계정이나 서비스 계정처럼 연결된 아이덴티티가 없는 계정에서 sudo를 실행하면 정책, MFA, 위험도 평가를 모두 건너뜁니다. 세션 모델은 Alpacon이 아는 아이덴티티를 통해 들어온 sudo만 다룹니다. 계정을 아이덴티티에 연결하면 이 공백을 줄일 수 있습니다.
둘째, Alpacon의 세션 레이어 밖에서 로컬 사용자로 호스트에 직접 SSH 로그인하는 경로입니다. Alpacon은 이제 이런 로그인을 탐지해 Governance → External access에 표시합니다. 다만 이 경로를 막을 수는 없습니다. 차단까지 담당하는 기능은 확정된 설계이지만 아직 출시되지 않았습니다. 그때까지 로컬 로그인과 그 안에서 실행하는 sudo는 세션을 열지 않고도 호스트에 접근할 수 있는 실제 경로입니다.
셋째, CI/CD나 벤더 통합에 쓰는 서비스 토큰과 개인 API 토큰입니다. 이 토큰으로도 Work Session 없이 권한 있는 명령을 실행할 수 있습니다. 서비스 토큰은 발급 시점에 관리자가 승인한 정적 ACL로 제어됩니다. 세션의 스코프·목적·TTL로 제어되지 않으므로 실행한 명령도 세션 모델의 시간 기준을 거치지 않습니다. 현재로서는 ACL을 좁게 설정하는 방법이 대응책입니다.
또 하나는 세션 모델 안에 있지만 root 계정으로 직접 연 세션입니다. 워크스페이스에서 기본값으로 꺼진 설정을 켠 경우에만 사용할 수 있으며, 세션이 유지되는 동안 이미 root 권한을 가집니다. 스코프를 둔 sudo 요청에 적용되는 sudo 정책, 사용자 참여 확인, 위험도 게이트는 거치지 않습니다. 판단을 거친 sudo 스코프가 부여했을 권한을 처음부터 보유합니다. 기본값대로 이 설정을 끄면 이 경로는 닫혀 있습니다.
세션 모델 안에서도 경로에 따라 적용 범위가 다릅니다. AI 판단 티어를 켠 경우 명령 API 경로인 exec lane으로 들어온 sudo 요청은 앞서 설명한 세 단계 검증 엔진을 거칩니다. 규칙, 기본 레이어, 회색 구간의 LLM 판단 순서입니다. 반면 대화형 Websh 세션의 sudo는 AI 판단 티어를 켜도 명령 내용을 평가하지 않습니다. 아이덴티티와 최근성만 확인합니다. 에이전트 모드 세션은 생성할 때 Websh 스코프를 쓸 수 없으므로, 에이전트의 sudo 요청은 위에서 설명한 exec lane으로만 들어옵니다. 사람이 대화형 셸을 쓰는 경우에는 이 경로를 거치지 않습니다. 사람의 Websh sudo는 아이덴티티와 최근성만 확인합니다.
sudoers가 답할 수 없는 질문
sudoers 파일은 파일에 이 아이덴티티가 있는지만 판단합니다. 명령이 실제로 무엇을 하든, 이것이 sudoers가 하도록 설계된 유일한 질문입니다. AI 판단 티어를 켠 환경에서 명령 API 경로로 들어온 sudo 요청은 이 권한 확인을 거친 뒤, sudoers가 할 수 없는 두 번째 질문도 받습니다. 허용 목록에 없는 이 명령이 위험한지입니다. sudoers 규칙은 세션이나 선언한 목적을 담지 않고 단순히 일치 여부만 확인합니다. Alpacon의 Work Session을 거친 명령에는 세션과 선언한 목적이 함께 따라옵니다. 명령 자체의 위험도도 매번 평가되고 기록됩니다. 배포 설정에 따라 그 결과가 실행에 반영되지 않을 수도 있습니다.
프로덕션 인프라에서 명령을 실행하는 에이전트와 사람의 OS 수준 권한을 어떻게 운영할지 결정하고 있다면, sudoers 파일을 잘 관리하는지보다 권한에 세션 경계가 있는지부터 검토해야 합니다.
FAQ
세션 경계가 모든 sudo 취약점을 막아주나요? 아닙니다. CVE-2026-35535처럼 sudo 내부의 권한 하향 처리 코드 자체에 있는 결함은 세션이 판단하는 범위보다 아래에 있어 세션 경계로는 막을 수 없습니다. 이후 각 호출에서 확인하는 질문은 달라집니다. sudoers 규칙은 누가 허용됐는지만 답할 수 있고, AI 판단 티어를 켠 Alpacon의 sudo 경로는 그 명령이 위험한지도 함께 묻습니다.
AI 판단 티어가 꺼져 있으면 sudo 판단은 어떻게 되나요? 명령 경로의 sudo는 sudoers와 같은 권한 확인만 거치고, 위험도 평가는 실행되지 않습니다. 셀프 호스팅 배포에서는 AI 판단 티어가 기본적으로 꺼져 있으므로, 특정 sudo 호출이 받는 판단은 요청 경로와 이 티어의 활성화 여부에 따라 달라집니다.
