.png)
뭐, 다양한 기사와 영상을 찾아보게 됐는데요. 그들은 모두 동일한 기본 사항을 말합니다. 즉, 기본 정책으로 시작하고 허용 모드에서 실행하여 수정해야 할 사항을 확인합니다. 그런 다음 전략을 수정하여 잠재적인 문제를 해결하세요. 그런 다음 다시 엄격한 시행을 시작합니다.
ausearch이 참조에서 그들은 더 단순화된 버전의 audit.log를 얻기 위해 실행을 제안했습니다 . 그래서 나는 다음과 같은 보고서를 시도했습니다.
type=PROCTITLE msg=audit(03/27/2015 02:58:34.764:439) : proctitle=/bin/sh
type=SYSCALL msg=audit(03/27/2015 02:58:34.764:439) : arch=x86_64 syscall=getxattr success=no exit=-61(No data available) a0=0x1fef030 a1=0x7fc0dbf2ef9f a2=0x7fff6aaa1da0 a3=0x84 items=0 ppid=1 pid=3861 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=systemd-logind exe=/lib/systemd/systemd-logind subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(03/27/2015 02:58:34.764:439) : avc: denied { getattr } for pid=3861 comm=systemd-logind name=kvm dev="devtmpfs" ino=11755 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:kvm_device_t:s0 tclass=chr_file permissive=1
특히 수백 개의 메시지를 접할 때 이 메시지가 무엇을 말하는지 파악하기가 어렵습니다.
결과 ausearch를 audit2allow. 이는 확인 상자가 나타날 때마다 수락 버튼을 누르는 것과 같습니다. 또한 메시지가 침입을 시도하는 해커가 아닌 버그로 인해 발생했다고 가정합니다.
그렇다면 SELinux 허용 모드의 "출력"을 분석하는 합리적인 방법을 제안할 수 있는 사람이 있을까요?
답변1
여러 번 당신은 어떤 정보를 받고 당신의 목적과 관련된 정보를 골라야 할 것입니다. 예를 들어, strace프로그램을 작성할 때 많은 양의 출력이 있고 출력을 보는 이유와 관련된 부분에만 집중합니다 strace.
감사 로그는 비슷한 원칙을 따릅니다. 당신의 것을 살펴 보겠습니다:
유형=PROCTITLE msg=audit(2015/03/27 02:58:34.764:439): proctitle=/bin/sh
그다지 흥미롭지 않습니다. 이는 타임스탬프와 실행 파일의 값 proctitle(일반적으로 프로세스 이름)을 제공합니다. 하지만 logind이것이 왜 프로그램 제목인지 는 확실하지 않습니다.
type=AVC msg=audit(03/27/2015 02:58:34.764:439) : avc: pid=3861 comm=systemd-logind name=kvm dev="devtmpfs" ino=11755 scontext=system_u에 대한 { getattr } 거부 :system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:kvm_device_t:s0 tclass=chr_file 권한=1
이것은 실제 SELinux 오류 메시지이며 가장 걱정해야 할 사항입니다. 그게 type=AVC바로 그거예요. AVC대표하다access vector cache 이것은 SELinux 구성 요소입니다..
주목해야 할 중요한 부분은 denied해당 섹션(이 경우 getattr)에 있는 내용으로, 프로그램이 거부되기 위해 구체적으로 수행한 작업을 알려줍니다. 그런 다음 scontext아이디어를 제공하는 소스 컨텍스트(일명)를 살펴봅니다.일반 카테고리이 경우 전체 맥락은 system_u:system_r:system_dbusd_t실질적인 부분(99%)으로 단축 됩니다 system_dbusd_t. 우리가 얻은 대상 컨텍스트에 대해 동일한 작업을 수행합니다 kvm_device_t. comm필드는 pid매우 중요하고 분명합니다. systemd-logindPID 3861을 사용하여 실행 중인 프로그램 에서 예외가 발생합니다 .
그러니 함께 모아봐systemd-logindcontext 가 있는 파일에 대해 system_dbusd_t일부 작업을 실행하고 수행 하려고 합니다 .getattrkvm_device_t
관리자는 이것이 무엇을 의미하는지, 무엇을 해야 하는지 알고 있습니다. SELinux는 해당 정책이 그러한 것을 허용하지 않는다는 것을 알고 있으므로 사용자가 직접 호출할 수 있도록 세부 정보를 제공합니다.
type=SYSCALL msg=audit(03/27/2015 02:58:34.764:439) : arch=x86_64 syscall=getxattr 성공=no exit=-61(사용 가능한 데이터 없음) a0=0x1fef030 a1=0x7fc0dbf2ef9f a2=0x7fff6aaa1da0 a3= 0x84 항목=0 ppid=1 pid=3861 auid=설정 해제 uid=루트 gid=루트 euid=루트 suid=루트 fsuid=루트 egid=루트 sgid=루트 fsgid=루트 tty=(없음) ses=설정 해제 comm=systemd-logind exe=/lib/systemd/systemd-logind subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 key=(null)
표현 방식이 좀 어긋나긴 했지만, 어떻게 읽어야 할지 이해하기 쉽기 때문에 나중에 넣습니다. 이것이 type=AVC중요한 부분이지만 일반적으로 실패한 실제 시스템 호출을 기록하므로 자세한 내용을 얻을 수 있습니다.
예를 들어, 프로그램 이름이 주어지면 systemd-logind그것이 무엇인지 알 수 있지만, 이름이 더 모호한 경우 exe=/lib/systemd/systemd-logind어떤 프로그램이 오류를 일으키는지 확인할 수 있습니다. auid( loginuid프로세스의) 또는 (프로세스의) 와 같은 정보는 문제의 실행 파일이 시작된 이유를 잘 모르는 경우에도 유용한 정보가 될 수 있습니다.uid
도움이 되길 바랍니다. 질문이 있으시면 답변을 업데이트하겠습니다.
편집하다:마지막 요점에 대해 한 가지 더. 일반적으로 audit2allow정책이 생성하는 내용을 살펴보고 정책에 따른 변경 사항을 이해할 수 있습니다. 정책 모듈을 삽입할 때까지 실제로 변경 사항이 적용되지 않습니다. 따라서 이를 생성한 다음 텍스트 편집기에서 보고 해당 일이 발생하도록 허용하려는지 확인할 수 있습니다. 직접 읽는 것보다 세부사항을 추적하는 것이 더 빠를 수 있습니다 audit.log.