terminated screencapture

맥스크린 캡쳐시 저장이 안되는 경우가 발생했다. 될 때는 되고 안될때는 안되던가 수초간의 딜레이가 발생 후 저장됐다

스크린 캡쳐 관련 프로세스는 다음 2개가 있다.

screencapture: cmd+shift+3/4 로 실제로 캡처를 수행하는 프로세스

screencaptureui: cmd+shift+5 로 화면 캡처 메뉴 UI 를 보여주는 프로세스

위 2개 프로세스를 모니터링(btop 등에서 screen 이름으로 필터링) 하고

cmd+shift+4 누르면 screencapture 가 실행되고 종료되지만 캡쳐가 되지 않거나 느리게 캡쳐된다.

다음과 같은 명령으로 영역 캡쳐 테스트시 캡쳐가 안되는 경우 강제 종료가 되고 있다는것을 알았다.

screencapture -R 0,0,100,100 -t jpg z.jpg

zsh: terminated  screencapture -R 0,0,100,100 -t jpg z.jpg

cmd+shift+5 누르면 screencaptureui 가 생겼다 사라진다.(메뉴가 잠깐 보였다 사라진다)

screenshot.app 앱도 실행하면 켭쳐메뉴가 바로 종료된다.

claude-code 으로 원인 파악을 해봤다.

screencaptureui(PID: 37344) 로그를 모니터링하면

/usr/bin/log show --last 2m | grep "37344" | grep -i "exit"

launchd가 프로세스 종료 시 자동으로 기록하는 로그에 원인이 포함되어 있었다.

launchd: [gui/501/com.apple.screencaptureui.agent [37344]:] exited due to SIGTERM | sent by TouchEN_TEWeb_Agent[854], ran for 285ms

원인은 TouchEN_TEWeb_Agent(금융/보안 프로그램)이였다.

TEWebUNInstall.pkg 를 실행해서 삭제하니 잘된다.

kerberos keychain 등록

# 커버로스 mac keychain 등록하기, 암호변경되면 keychain 에서 변경

# Usage: add-generic-password [-a account] [-s service] [-w password] [options...] [-A|-T appPath] [keychain]

# -l  Specify label (if omitted, service name is used as default label)

# -c  Specify item creator (optional four-character code)

security add-generic-password -a "ysoftman" -l "lemon.com (ysoftman)" -s "lemon.com" -w 'password123' -c "aapl" -T "/usr/bin/kinit"

firefox esni, trr 기능

# https 암호화 전 접속 호스트명 SNI(Server Name Indication)가
# 암호화 되지 않아 ISP 에서 차단하는 사이트가 많은데,
# ESNI(Encrypted SNI)와
# TRR(Trusted Recursive Resolver)를 사용할 수 있는
# firefox 를 사용하면 차단 없이 접속 가능하다.

# firefox about 프로토콜에서 다음과 같이 설정한다.
about:config -> network.security.esni.enabled -> true
about:config -> network.trr.bootstrapAddress -> 1.1.1.1
about:config -> network.trr.uri -> https://mozilla.cloudflare-dns.com/dns-query
about:config -> network.dns.echconfig.enabled -> true
about:config -> network.trr.mode -> 3

# trr.bootstrapAddress(1.1.1.1) 로 trr.uri 주소를 파악하게 된다.
# trr.mode
# 0: native resolver (default)
# 1: native resolver, trr 중 응답 빠른것을 사용
# 2: trr 시도 후 안돼면 native resolver 사용
# 3: trr 만 사용
# 4: reserved(shadow mode 로 추가될 예정)

# firefox about 프로토콜 설명
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/The_about_protocol

# 85버전 부터는 ESNI 대신 보안이 더 강화된 ECH(Encrypted Client Hello)를 사용한다.
# ECH 모드를 활성화 하려면 다음 2개 설정을 활성화 해야 한다.
about:config -> network.dns.echconfig.enabled -> true
about:config -> network.dns.use_https_rr_as_altsvc -> true

# ESNI -> ECH 설명에서 설정 방법 참고
https://blog.mozilla.org/security/2021/01/07/encrypted-client-hello-the-future-of-esni-in-firefox/

nginx 홈디렉토리의 정적 리소스 접속 403 에러

nginx 를 사용자 홈디렉토리(/home/ysoftman/nginx) 에 설치하였다.

보안상의 이유로 nobody 계정으로 nginx 를 시작하였다.

그리고 index.html favicon.ico  check.txt(헬스체크를 위한)등의 정적 리소스도 /home/ysoftman/nginx/html/으로 서비스를 할때

http://localhost/check.txt 접속을하면 403 에러가 발생한다.

원인은 /home/ysoftman 의 other 권한에 x(실행)권한이 없어서다.

실행 권한을 주면 된다.

r(읽기) 권한만 줘면 안된다.

/home 의 other 에도 x권한이 있어야 한다.

즉 nginx static 절대 경로의 모든 other +x 가 있어야 한다.

+x추가한 사례: https://gist.github.com/jhjguxin/6208474

보안상의 이유로 other 권한에 실행권한을 줄수 없다면

# 방법1
# 루트 경로나 /home 아래에 html 디렉토리를 옮기고 이쪽으로 정적 리소스를 서빙한다.

# nginx.conf 설정에서 /check.txt 의 루트 디렉토리를 다음처럼 변경한다.
location /check.txt {

    allow all;
    root   /home/html;
}

# /home/html other 권한에 +x 추가한다.

sudo chmod -R +x /home/html

# 방법2
# nobody 계정의 그룹에 ysoftman 그룹을 추가한다.
sudo groupadd ysoftman

# 그룹확인
groups nobody

cpu meltdown, spectre 취약점

인텔 CPU 멜트다운(meltdown) 과 스펙터(spectre) 취약점(vulnerability)이 이슈인데, 왜 문제인지 대략적으로 알아보자.

참고 http://blog.alyac.co.kr/1472

우선 CPU 는 명령 처리를 위해 L1 과 같은 cpu 캐시에 명령관련 데이터를 로딩(준비)해두어야 한다. 단순히 cpu 가 들어오는 명령어만 그때 그때 처리 한다면 다음 명령이 왔을때 필요한 데이터를 캐시로 로딩하는 시간에 cpu 는 놀고 있게 된다. 그래서 cpu 는 다음 실행할 명령을 예측하고 예측된 명령어 관련된 데이터를 cpu 캐시인 L1 미리 로딩을 해둔다고 한다.
예측 명령이 맞다면 캐시에 로딩된 데이터와 함께 검증되고 이 캐시데이터는 보호받게 되는데 예측한 명령이 실패(맞지 않는다면)한다면 어떻게 될까? 이미 캐시에 로딩된 데이터는 그대로 남아 있는 상태가 되고 이 캐시의 데이터는 누구나 접근할 수 있다.
예측 실패할때 meltdown 은 OS 커널 영역의 메모리 데이터가 캐싱되어 있었다면 보호되지 못하고 사용자 영역의 프로세스(해커의 프로세스)에서 커널 메모리를 파악하게 되는 경우다.

예측 명령 실패 cpu L1(OS 커널 메모리 올라와 있는 상태) <-- user level 프로세스에서 접근

spectre 의 경우는 원래 OS 가 사용자 레벨의 프로세스들은 결리 되어 다른 프로세스의 메모리에는 접근 못하게 하는데, A라는 프로세스의 어떤 명령이 예측되어 cpu 캐시되어 있는데 실패된 예측이라 해커의 B라는 프로세스가 캐싱 데이터에 접근하게되어 결국 B가 A 프로세스의 메모리를 엿보게 되는 꼴이 된다.

예측 명령 실패 cpu L1(A 프로세스 메모리 올라와 있는 상태) <-- B 프로세스에서 접근

자세한 내용을 좀더 알아봐야겠지만 결론적으로 meltdown, spectre 모두 cpu 예측 명령 실패로 인해 캐싱 데이터가 보호되지 못해서 발생되는 kernel / user 레벨간,  user process 간의 격리되지 못하고 침범되는 문제이다.
cpu 의 하드웨어적 설계 결합이라 쉽게 고칠수가 없을것 같은데, 역시 아직까지 나온 OS 등의 소프트웨어 패치들은 cpu 성능이 아주 저하된다고 한다. 안정된 버전의 패치나 해결방법이 나오기 까진 좀더 시간이 걸릴것으로 보인다. 흠...