0. 들어가며

Rocky OS를 운영하며 제목과 같은 에러가 주기적으로 /var/log/messages에 발생하는것을 확인 할 수 있었습니다.

해당 메시지는 crontab에 등록된 작업이 실패 할 경우에 다량으로 발생하는것을 확인하였는데,

이 글은 위에 대한 조치 방안에 대해서 작성하였습니다.

1. 발생 원인

cron은 기본적으로 작업 실행 결과에 대한 내용을 메일로 발송하게끔 구성되어있습니다.

이로 인해  crontab에서 시행한 결과를 발송하려했으나, 서버내에 메일에 대한 설정이 없을 경우에

제목과 같은 에러가 발생합니다.

 

2. 조치 방안

조치 방안은 크게 두가지 방안이 있습니다.

 

2-1) 메일 프로세스 설치

간단한 조치 방법으로 메일서버를 설치해주면 해당 에러는 더이상 발생하지 않습니다.

[root@test ~]# dnf install postfix

==============================================================================================================================================================================================================
 꾸러미                                          구조                                           버전                                                     저장소                                          크기
==============================================================================================================================================================================================================
설치 중:
 postfix                                         x86_64                                         2:3.5.8-7.el8                                            baseos                                         1.5 M

연결 요약
==============================================================================================================================================================================================================

 

2-2) crond mail disable

서버 용도, 환경에 따라 메일 서버 설치가 어려운 경우에 crond 실행 결과 메일 발송을 비활성화 할 수 있습니다. 

man crond 중에 -m 옵션에 대한 내용입니다.

[root@test ~]# man crond
##중략##
-m     This  option allows you to specify a shell command to use for sending Cron mail output instead of using sendmail(8) This command must accept a fully formatted mail message (with headers)
              on standard input and send it as a mail message to the recipients specified in the mail headers.  Specifying the string off (i.e., crond -m off) will disable the sending of mail.

 

뒤에 내용을 보면 -m off를 통해 크론메일전송을 비활성화 할 수 있다는 내용이 있습니다.

아래와 같이 설정 및 재기동 해줍니다.

[root@test ~]# vi /etc/sysconfig/crond

# Settings for the CRON daemon.
# CRONDARGS= :  any extra command-line startup arguments for crond
CRONDARGS="-m off"

[root@test ~]# systemctl restart crond

 

 

 

'System > Linux' 카테고리의 다른 글

SELinux permissive mode logrotate issue  (0) 2024.08.01

0. 들어가며

미들웨어와 같은 어플리케이션 로그 관리를 위하여 별도의 경로에 로그를 보관하는 경우가 자주 있다.

로그에 대한 관리를 위해서 logrotate.d에 설정파일을 추가하여, cron.daily를 통해 내부 정책에 맞춰 관리를 진행하는데,

SELinux가 켜져있는경우 logrotate가 정상적으로 돌지 않았다.

이 경우 간단한 해결방법은 /etc/sysconfig/selinux(Rhel8 이상에서는 /etc/selinux/config)에서 SELINUX=disabled로 변경 후 리부팅하면 getenforce 명령어를 통해 확인 시 disabled 모드로 변경되며 정상적으로 logrotate가 되는 걸 확인할 수 있다. 

[root@localhost /]# sestatus
SELinux status:                 disabled
[root@localhost /]# getenforce
Disabled

 

물론 setenforce 0 명령어를 통해 permissive mode로 변경하면 허용모드로써, audit.log에 기록만 남기고 정상 동작해야 하지만, 필자의 경우 이상하게 logrotate가 정상 동작하지 않았다.

관리하는 서버 중에 리부팅이 당장 어려운 라이브 서버의 경우, 어떻게 조치해야 할지 아래와 같이 정리해 봤다.  

 

1. SELinux?

우선 SELinux에 대해 간단히 알아야 하는데, 리눅스 커널에 내장된 보안기능 중 하나로 MAC(Mandatory Access Control) 기반으로, 파일과 같은 리눅스의 리소스에 대한 접근 권한을 제어할 수 있는 기능이다.
주체(프로세스, 파일 등)가 객체에 접근 가능한지 세부적인 규칙을 설정할 수 있게 된다.

이 세부적인 규칙을 보안콘테스트 또는 label이라고 표현하는데 label의 구성요소는 아래와 같다.

사용자(User) 역할(Role) 유형(Type) 레벨(Level)
unconfined_u object_r file_t s0

위의 값들은 seinfo(setools-console 패키지)라는 명령어를 통해 값을 알아낼 수 있다. 

#user 정보
[root@localhost ~]# seinfo -u

Users: 8
   guest_u
   root
   staff_u
   sysadm_u
............중략.......................

#role 정보
[root@localhost ~]# seinfo -r

Roles: 15
   auditadm_r
   container_user_r
   dbadm_r
   guest_r
   logadm_r
   nx_server_r
............중략.......................

#type 정보
[root@logmonitor ~]# seinfo -t

Types: 5008
   NetworkManager_etc_rw_t
   NetworkManager_etc_t
   NetworkManager_exec_t
   NetworkManager_initrc_exec_t
   NetworkManager_log_t
   NetworkManager_priv_helper_exec_t
   NetworkManager_priv_helper_t

상세한 내용은 여러 블로그에 설명이 되어있기에 생략하겠다. 위 내용에서는 주체와 객체가
Context기반의 룰을 통해  접근을 한다는 것을 알고 있으면 된다.

2. 원인 파악

 Permissve Mode에서 파일 접근이 정상적으로 안되는 것은 버그일 가능성이 높다. 이 부분에 대한 원인은 파악이 힘들 것으로 보여서, SELinux 쪽을 손봐서 조치하려고 한다. 생각해 보면 결국 주체(logrotate process)가 객체(대상 log)에 대한 권한이 없어서 에러가 발생한 것으로 보인다. 아래는  /var/log/audit/audit log에 기록된 내용이다.

type=AVC msg=audit(1722364339.895:4267124): avc:  denied  { read } for  pid=69758 comm="logrotate" name="/" dev=sdb1 ino=2 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=dir
type=SYSCALL msg=audit(1722364339.895:4267124): arch=c000003e syscall=2 success=yes exit=4 a0=7ffe9f7d07d0 a1=90800 a2=7ffe9f7d0a7e a3=fffffffffffffff0 items=0 ppid=69756 pid=69758 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=171358 comm="logrotate" exe="/usr/sbin/logrotate" subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1722364339.895:4267125): avc:  denied  { read } for  pid=69758 comm="logrotate" name="logs" dev=sdb1 ino=131074 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:file_t:s0 tclass=dir
type=SYSCALL msg=audit(1722364339.895:4267125): arch=c000003e syscall=2 success=yes exit=4 a0=c777f0 a1=90800 a2=c77755 a3=15 items=0 ppid=69756 pid=69758 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=171358 comm="logrotate" exe="/usr/sbin/logrotate" subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1722364339.896:4267126): avc:  denied  { getattr } for  pid=69758 comm="logrotate" path="/LOG/tomcat/logs/tomcat.catalina.out" dev=sdb1 ino=524295 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:file_t:s0 tclass=file

cron.daily를 통해 logrotate가 돌 경우 위와 같은 로그가 남게 되는데 해석을 해보면 주체(scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023)가 해당 보안콘텍스트로 객체(tcontext=system_u:object_r:file_t:s0)에 접근했을 때 denied가 떨어지는 걸 확인할 수 있다.
그러나 내용에 보면 success=yes가 있는데 이 경우에는, system call이 정상적으로 진행되었다는 걸 알 수 있다. 

*즉 selinux는 permissive mode가 정상 동작하고 있음을 알 수 있지만, rotate를 통한 로그 파일은 생성되지 않고 있다. 

 

그렇다면, 위에서 말한 것처럼 selinux정책을 통해 조치를 해야 하는데, 정책을 한번 살펴보자 logrotate_t에서 file_t에 대한 접근을 확인해 보면 되는데, sesearch -A 명령어를 통하여 아래와 같이 정책을 확인할 수 있다.

[root@localhost /var/log/audit]# sesearch -A -s logrotate_t -t file_t
Found 1 semantic av rules:
   allow logrotate_t file_type : dir { getattr search open } ;

[root@localhost /var/log/audit]# sesearch -A -s logrotate_t -t logrotate_exec_t
Found 4 semantic av rules:
   allow logrotate_t file_type : dir { getattr search open } ;
   allow logrotate_t entry_type : file getattr ;
   allow logrotate_t entry_type : lnk_file { read getattr } ;
   allow logrotate_t logrotate_exec_t : file { ioctl read getattr lock execute entrypoint open } ;

> 위 내용대로 logrotate_t에서 file_t에 대해 file정책은 없는걸 확인 할 수 있다.

즉, logrotate_t에서 file_t에 대한 정책 차단으로 생성이 안되는 걸 의심할 수 있다.

 

2. 조치 방안

logrotate_t에서 허용되는 type으로 콘텍스트를 지정해 준다면 정상적으로 생성될 것으로 보인다.

위에서 sesearch로 확인한 logrotate_exec_t로 변경을 진행하겠다.

 

2-1. 마운트시에 context 지정을 통해 상속받게끔 하기

 

selinux가 활성화되어있을 때, 마운트를 할 경우 label을 지정하여 마운트 할 수 있다. 하지만 일반적인 마운트를 할 경우

기본값으로 가져가게끔 되어있다. 아래와 같이 context를 지정하여 마운트를 하면 내부 디렉터리 및 파일 역시 label을 상속하여 동일한 label을 가지고 생성된다.

[root@localhost #]mount /dev/sdb /LOG -o \ context="system_u:object_r:logrotate_exec_t:s0"

 

2-2. 경로 context를 직접 변경

 

마운트의 경우 remount를 해야 하는데, 라이브서버이기에 LOG디렉터리 자체 context를 변경하여 진행하기로 한다. 

아래와 같이 옵션을 넣어주면 /LOG 하단의 모든 디렉터리, 파일의 context가 변경된다.

[root@localhost #]chcon -Rv --type=logrotate_exec_t /LOG

 

3. 결과 

 

작업 전 테스트를 위해 아래와 같이 logrotate_exec_t 타입 외에 두 개의 type을 임시로 생성하여 lotate테스트를 진행하였다.

[root@localhost /LOG]#ls -Z
-rw-r--r--. root root unconfined_u:object_r:tomcat_log_t:s0 tomcat_log_t_zosys.test.catalina.out
-rw-r--r--. root root unconfined_u:object_r:logrotate_t:s0 logrotate_t.zosys.test.catalina.out
-rw-r--r--. root root unconfined_u:object_r:file_t:s0  file_t_zosys.test.catalina.out

logrotate를 돌리기 전에 관련 정책을 확인해 보면 아래와 같다.

[root@localhost ~]# sesearch -A | grep logrotate | grep file_t
allow logrotate_t file_type:dir { getattr open search };
[root@localhost ~]# sesearch -A | grep logrotate | grep tomcat_log
[root@localhost ~]# sesearch -A | grep logrotate | grep logrotate_exec
allow logrotate_exec_t logrotate_exec_t:filesystem associate;

위와 같이 변경 후 예상 결과는 logrotate_exec_t 외에는 logrotate가 안 돌 것으로 예상된다.

익일 cron.daily를 통해 logrotate 확인 시에 예상과 같이 logrotate_exec_t는 정상적으로 돌고,
나머지 두건에 대해서는 logrotate가 안된 것을 확인하였다.

두건 중 file_t의 경우 위에서 확인된 정책으로 인하여 차단된 내역이 아래처럼 audit 로그에 찍혔으며, 룰이 없더라도 기본적으로 deny가 되기에 tomcat_log_t는 로그에 별도로 남겨지진 않았다. 

type=AVC msg=audit(1722451159.604:4268579): avc:  denied  { getattr } for  pid=87576 comm="logrotate" path="/LOG/file_t_zosys.test.catalina.out" dev=sdb1 ino=131746 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:file_t:s0 tclass=file

'System > Linux' 카테고리의 다른 글

No configuration file found at /root/.esmtprc or /etc/esmtprc  (2) 2024.10.04

+ Recent posts