`/proc`에 procf가 필요한 이유는 무엇입니까?

기다리다. "/proc에 있는 내용이 실제 파일 시스템이 아니라 의사 파일 시스템(647551)이라는 것을 알고 있습니다."라고 말씀하셨습니다.

용서해 주세요만, 읽으신 것을 생각하면저것, 귀하의 질문은 거의 의미가 없습니다. 너필요시스템 API 호출 /proc"filesystem"은파일로 렌더링되는 API 호출. 즉, 프로세스 API의 파일 가용성으로 인해 잃을 것도 없고 얻을 것도 없습니다.사용법이 다소 간단할 뿐만 아니라. procfs 파일을 통해 수행할 수 있는 모든 작업은 해당 ioctl/kernel 호출을 사용하여 수행할 수 있습니다.

유사 파일 시스템을 제거하고 API를 유지하는 것이 예시입니다.모호함을 통한 보안, 그래서 모호한 것이 없을 것입니다. 가해자는 곧 다른 매크로 포함 파일을 로드하면 됩니다.

마찬가지로 이는 procfs성능 문제도 아니고 보안 문제도 아닙니다.

(이건 확실히아니요물론, 이러한 API에 대한 액세스를 보호하거나 악용을 방지해서는 안 됩니다! )

왜 우리는 아직 /proc거기에 있습니까?

ps귀하의 프로세스에 대해 읽을 수 있도록 이를 보유하고 있습니다 . 이는 디버깅 중이거나 실행 중인 백그라운드 프로세스가 길을 잃고 이를 종료하고 싶을 때 유용합니다. 먼저 그것을 찾아야합니다.

글쎄, 확실히 /proc그러한 정보를 제공하는 유일한 방법은 아닙니다. 전설에 따르면 옛날에는 권한 있는 ps바이너리가 있었다고 합니다.커널 메모리에서 직접 프로세스 정보 읽기. 관련된 파일은 없지만 더 안전하다고 느껴지지는 않습니다. 물론 세 번째 옵션은 프로세스 정보를 찾기 위해 하나 이상의 전용 시스템 호출을 만드는 것입니다. 여기에서 파일 시스템을 만드는 것은 디자인 선택입니다. 아마도 파일 시스템이 만들어졌을 때 사람들 은 ls. cat또한 이는 단지 정보를 처리하는 것이 아니라 전체 프로세스가 커널과 사용자 공간 간 전송에 유용한 모든 종류의 임의 데이터에 대한 게이트웨이 역할도 합니다. 이를 파일 시스템으로 만들면 계층을 위한 기성 프레임워크가 제공됩니다.

또한 파일 시스템에는 proc사용할 수 있는 기존 액세스 제어 시스템이 있습니다.

파일 시스템과 같은 procf를 나열하면 이러한 "파일"에 대한 읽기 및 쓰기가 잠재적으로 위험할 수 있습니다.

자신이 소유한 프로세스에서만 작동합니다. 전통적으로 단일 사용자에 대한 프로세스는 크게 분리되지 않았습니다. 도대체 일부 시스템에서는 실행 중인 프로세스에서 디버거를 실행한 다음 실행할 수 있습니다.당신이 원하는 것이 무엇이든 상관 없습니다그것에. (그러나 /proc/sys/kernel/yama/ptrace_scopeLinux에서는 어떤 일이 일어나는지 살펴보십시오.)

이는 특정 취약점(예: 프로세스 파일에 대한 읽기/쓰기 액세스)에 대한 문을 엽니다.

비디오에 제시된 문제는 에 관한 것이 아니라 proc파일 설명자를 열어 둔 다음 우선 순위가 낮은 컨텍스트(다시 사용자 자신의 UID로)로 변경하는 것에 관한 것 같습니다. 거기서 그들은 fd를 여는 쉘을 실행한 다음 쉘에게 cat해당 fd를 직접 읽도록 지시합니다. 이는 없이도 수행할 수 있으며 proc, 보기가 더 어렵더라도 fd는 없이도 존재합니다. 하지만 가장 낮은 것부터 순서대로 할당되기 때문에 fd가 어떤 숫자를 얻게 될지 추측하는 것은 어렵지 않습니다.

또한 해당 비디오에서 반환 값을 확인하지 않았기 setuid()때문에 전체 루트 권한으로 셸을 실행할 수 있었습니다. 또한 지시한 대로 루트로 컴파일러를 실행하지 마십시오. 컴파일러가 어떤 상황에서도 의도적으로 악의적인 작업을 수행하지 않을 것이라는 점을 신뢰해야 합니다. 그러나 이는 큰 문제이고 심지어 버그가 있을 수도 있으며 루트로 실행하면 노출 위험이 높아집니다.

Setuid 바이너리는딱딱한올바른 일을 하십시오. 길을 잃은 파일 설명자 외에도 다른 많은 이유가 있습니다. 여기에는 권한 있는 프로그램에서 권한 없는 프로그램으로의 복귀뿐 아니라 setuid 프로세스가 상속하는 환경도 포함됩니다.방문객, 일반 사용자가 제어하는 ​​프로세스입니다.

procfs는 아마도 일반화 및 단순한 설계를 위해 의사 파일 시스템으로 만들어질 수 있지만 Linux는 프로세스 내용을 노출하지 않고 메모리에 모든 것을 유지할 수 있어야 합니다.

틀림없이. 마운트하지 마십시오 /proc. 명시된 바와 같이 당신은 직업이 없습니다 ps. 그러나 파일 시스템이므로 실행만 하면 chmod 0550 /proc루트와 그룹 소유 구성원만 /proc액세스할 수 있습니다.

/proc/$pid/fd아니면 뭔가 특별한 것을 말씀하시는 건가요 ? 그것하다부모로부터 물건을 상속받는 프로세스의 일반적인 개념에서는 허용되지 않는 몇 가지 이상한 트릭이 허용되며, 그것 없이도 많은 일을 할 수 있으므로 제거하는 것이 합리적일 수 있습니다. 하지만 그 자체로는 별로 좋은 일을 하지 않으며, 사용자의 프로세스는 여러 가지 방법으로 서로 간섭할 수 있습니다.

1. procfssys코드를 작성하지 않고도 시스템의 현재 상태에 대한 정보를 얻을 수 있습니다 . 그래서 그것이 만들어졌습니다.

2. 파일 대신 C API를 사용하면 고유한 단점이 있습니다. 예를 들어, API가 생성되면아니요이러한 API를 사용하는 기존 애플리케이션을 다시 작성/수정해야 하므로 쉽게 확장할 수 있습니다.

예, procfs파일을 sys사용하여 시스템을 악용할 수 있지만 실제로는 일반 API가 이 목적으로 사용됩니다.더.

그것은완벽한이러한 파일 시스템은 전체 경험을 얻기 위해 설치하거나 사용할 필요조차 없습니다. 예를 들어 FreeBSD/OpenBSD/NetBSD, QNX 등과 같은 다른 POSIX 호환 운영 체제를 확인하세요.