KR20020033859A

KR20020033859A - 리눅스 보안 커널

Info

Publication number: KR20020033859A
Application number: KR1020000064017A
Authority: KR
Inventors: 송영호
Original assignee: 송영호; (주)나일소프트
Priority date: 2000-10-30
Filing date: 2000-10-30
Publication date: 2002-05-08

Abstract

본 발명은 최근 사용이 증가하고 있는 리눅스(Linux) 운영체제(OS:Operating System)를 대상으로 리눅스 서버의 안전한 정보시스템 보안 환경을 제공하면서 네트워크를 통해 들어오고 나가는 사용자에 대한 강력한 인증 기능, 파일을 포함한 리눅스 자원의 접근 권한 제어, 보안정책에 따른 감사 및 로그 기능과 실시간 모니터링 기능 등을 수행한다.

따라서, 본 발명은 보안 커널 모듈과 관리시스템으로 구성되며, 보안 관리시스템은 사용이 편리한 GUI(Graphic User Interface)로 운영되고 일괄적이고 중앙 집중식으로 보안 관리를 할 수 있다.

특히, 본 발명은 안전한 리눅스 보안 환경 및 리눅스 자원의 접근 제어 기능은 어플리케이션 레벨이 아닌 리눅스 운영체제 커널(kernel) 모듈 레벨에서 구현되어 새로운 커널을 생성하거나 기존 리눅스 유틸리티를 변경할 필요가 전혀 없어서 리눅스 운영체제 업그레이드시 대처가 용이하고 시스템관리가 간편하다.

Description

리눅스 보안커널{Linux Security Kernel}

본 발명은 리눅스의 보안커널에 관한 것으로, 리눅스 커널은 버전을 거듭할수록 크기가 증가하는 추세이므로 커널 함수들의 지속적인 발전과 확장뿐 아니라 새로운 장치 드라이버의 증가 덕분으로 리눅스가 비록 단일 시스템이기는 하지만 모든 장치 드라이버와 사용되는 파일 시스템은 커널에서 영속적으로 결합된다. 이는 우선 환경이 변할 때 커널은 재 컴파일 되어야 하고 다른 한편으로는 드라이버와 파일 시스템이 거의 사용되지 않더라도 메모리에서 지속적인 공간을 확보해야 한다는 뜻이다. 다른 불이익은 새로운 커널 코드는 개발자에게 직접적으로 느끼게 해 줄 것이고, 사소한 수정이 있더라도 새로운 커널이 생성되고 인스톨되면서 컴퓨터를 재부팅 시켜야만 한다.

그러나 커널의 관점에서 모듈은 대개 많은 함수로 구성되고 실행 시간에 연결되어 제거 가능한 오브젝트 코드로 이루어져 있다. 이 오브젝트 코드는 시스템 모드에서 돌아가는 것과 똑 같은 권한으로 커널을 돌리는데 사용된다. 커널의 단일한 구조는 변하지 않고, 마이크로 커널과는 달리 새로 추가된 함수는 스스로는 실행되지 않는다. 모듈로서 장치 드라이버나 파일 시스템을 실행시키는 한가지 이점은 오직 문서화된 인터페이스만이 사용될 수 있고, 사용자를 위해서 모듈은 작고 간단한 커널이 필요할 때마다 추가되는 다른 함수들과 사용할 수 있게 된다. 따라서, 사용자가 신경쓸 필요없이 모듈을 자동으로 로드하는 것이 가능하다. C 파일은 다양한 종류의 기능 그룹으로 구성된 디렉토리로 조직되어 있다. 컴파일 중 기능적 소단위들은 오브젝트 파일로 모아져서 대개 커널이 로드될 때 모든 오브젝트 파일에 개별적으로 접근할 필요가 없다. 이 기능적 단위는 종종 모듈로 사용된다.

리눅스 커널 모듈의 실행을 위해 리눅스 시스템은 세 가지 시스템 콜(create_module, init_module, delete_module)을 제공한다. 더 나은 시스템 콜은 커널 심볼 테이블의 복사본을 얻기 위해서 사용자 프로세스로서 사용된다. 리눅스에서 모듈의 감독은 로드된 모든 모듈을 포함하는 리스트를 사용하는 것이다. 이 리스트는 또한 모듈의 심볼 테이블과 레퍼런스를 감독한다. 커널에 관한 한, 모듈은 시스템 콜인 create_module과 init_module에 관련된 2가지 단계로 로드된다. 사용자 프로세스에서 이 과정은 4단계로 구분된다.

1단계, 프로세스는 오브젝트 파일의 내용을 자신의 주소 공간에 넣는다. 정상적인 오브젝트 파일에서 코드와 데이터들은 로드된 후, 주소 0에서 시작한 것처럼 정렬된다. 코드와 데이터를 실제 수행되는 방식으로 폼에 넣기 위해선 실제적인 로드 주소는 다양한 관점에서 추가된다. 이 프로세스는 할당(relocating)으로 알려져 있다. 요구된 부분으로의 참조는 오브젝트 파일에서 포함된다. 오브젝트 파일에서 해결되지 않은 레퍼런스가 있을 수 있다. 오브젝트 파일이 분석될 때 오브젝트 모듈의 크기는 또한 얻어진다.

2단계, 시스템 콜 create_module은 먼저 오브젝트 모듈의 첫번째 주소를 얻기 위해서고 두번째로는 이에 대한 메모리를 준비하기 위해 사용된다. 이를 위해 구조 모듈은 모듈의 리스트에서 모듈로 들어가고 메모리는 배정된다. 반환 값은 모듈이 나중에 카피될 주소를 돌려준다.

3단계, create_module에 의해서 건네진 로드 주소는 오브젝트 파일을 재할당시키는데 쓰인다. 이 프로시저는 오브젝트 파일에 따라 메모리 영역을 대신한다. 이 점에서 오브젝트 모듈은 정확한 주소에 있지 않고 커널 세그먼트 안의 모듈의 로드 주소에 재위치된다. 해결되지 않은 참조는 리눅스가 시스템 콜 get_kernel_syms()를제공함으로 커널 심볼을 사용하여 해결될 수 있다. 함수가 호출될 때 리눅스는 다른 두 경우 사이의 구별을 한다. 널 포인터가 매개변수로 건네질 때 커널 심볼 테이블의 사이즈를 알아내는 것을 가능하게 한다. 다른 매개변수가 사용되었다면 지시된 위치는 메모리에 심볼 테이블의 복사본을 제공한다. 이것은 우선 테이블의 사이즈를 결정하고 관계된 메모리의 용량을 요구하고 시스템 콜 get_kernel_syms()를 다시 사용하게 하는 프로세스를 가능케 한다. 주소를 제외하곤 테이블에 어떠한 종류의 타입정보도 없다. 그러므로 모듈을 개발하는 동안 정확한 헤더파일이 포함되었는지 확인하는데 주의해야 한다. 가장 유연해지기 위해 모듈은 스스로 심볼을 커널 심볼 테이블에 추가 시킬 수 있다. 이는 다른 모듈이 먼저 로드된 모듈로부터 함수를 사용할 수 있게 한다. 이 매커니즘을 모듈스테킹(module stacking)이라 한다. 모듈에서 나온 모든 테이블은 독립된 심볼 테이블로 수집된다.

4단계, 일단 예비적인 작업이 끝났다면 우리는 오브젝트 모듈을 로드할 수 있다. 이는 그 매개변수 중에서 구조체 mod_routines와 그 모듈의 심볼 테이블에 포인터를 주는 시스템 콜 init_module을 사용하게 한다. 모듈 감독 함수들은 mod_routine구조로 제시되고 리눅스는 오브젝트 모듈을 커널 주소 공간에 카피한다. 감독함수 init()는 코드와 데이터가 인스톨될 때 단 한번 불러지고 적절한 레지스터 함수도 또한 불러져야 한다. 반환 값은 인스톨 프로시저가 성공적인지를 판단한다. 두번째 감독함수 cleanup()은 모듈이 해제될 때 불러지고 적절한 레지스터 함수가 초기화된다.

커널에서의 심볼 테이블은 파일 kernel/ksyms.c 에서 정의된다. 각 추출된 함수는 symbol_테이블에 엔트리를 가지고 있다. 각 경우의 함수와 변수의 이름은 macro X()에 의해 symbol_테이블로 변환된다. 모듈의 심볼 테이블은 추출된 심볼 뿐만 아니라 또한 모듈에 의해 사용된 커널에서의 심볼로의 참조도 보여준다. 이는 모듈의 상호종속성이 측정될 수 있게 해준다. 결국 다른 모듈에 의해 사용되고 있는 모듈은 해제되지 않을 것이다. 사용 후 모듈을 해제할 때 발생하는 문제를 피하는데 추가적인 도움은 USE_COUNT 매커니즘이다. 예를 들어 우리가 장치 드라이버를 모듈로서 실행했고 로드되었다면 사용 카운터는 모듈이 열릴 때마다 증가하고 닫힐 때마다 감소할 것이다. 이는 모듈을 해제할 때 그것이 아직도 사용 중인지 확인할 수 있다는 것을 의미한다. 사용 계수가 면하는 위치는 때때로 찾기 어렵거나 불가능할 때도 있다는 것을 언급해야 한다.

특히 다른 경우의 최후 수단으로서 init() 함수가 수행되는 동안 사용 계수를 전용 오퍼레이션으로 증가시키는 것도 가능하다. 이는 모듈은 결코 제거될 수 없다는 것을 의미한다. 모듈의 유연성은 그들이 동적으로 로드될 수 있다는 사실에 달려 있지 않다. 시스템 콜 delete_module을 사용함으로써 로드된 모듈은 다시 제거될 수 있다. 두 가지 전제는 여기서 언급할 필요가 있다. 모듈로의 참조는 없어야 하고 모듈의 사용계수는 0값을 가져야 한다. 모듈이 끝나기 전에 인스톨되는 동안 등록된 cleanup() 함수가 호출된다. 이 함수에서 실행동안 요청된 동적인 자원은 init()함수에서 해제될 수 있다.

모듈이 시작했을 때 모듈이 정상적으론 ISA버스의 하드웨어 자원을 자동적으로 인식하지 못하기 때문에 때때로 I/O주소나 ISA장치에 사용되는 인터럽트 같은 매개 변수를 건네줄 필요가 있다. 그러므로 모듈은 숫자나 문자열 매개 변수로 넘겨질 수 있다. 모듈 내부에는 매개 변수 이름을 가지고 있는 int, int[],char *형태의 변수들이 정의되어 있다. 모듈이 로딩되는 동안 변수는 지정된 숫자의 매개 변수로 초기화된다. 문자열 매개 변수가 먼저 배정되고 다음 표와 같이 포인터가 조정된다.

static int io[MAX_IO] = { 0, };static char *name = NULL;int init_module(void){int dev;for ( dev = 0; dev < MAX_IO; ++dev ) {if ( io[dev] ) {/* address was passed */}if ( name ) {/* name was passed */}}}

insmod 모듈 io=0x300.0x308 name = “test”로의 호출은 io배열을 0x300과 0x308로 이름 포인터를 건네진 문자열로 초기화시킨다.

리눅스 커널 버전 2.0의 장점 중에 하나는 커널 데몬이다. 이는 모듈의 로딩과 제거를 시스템 사용자가 알아차리지 못하게 자동으로 수행하는 프로세스를 말한다. 리눅스 커널과 커널 데몬 사이의 교류는 IPC를 통해서 수행된다. 커널 데몬은 플래그(flag)의 IPC_KERNELD로 메시지 큐를 연다. 이 큐는 자동으로 커널 데몬을 위한 메시지 큐로 커널에 의해 사용된다. 이러한 제안을 위해 존재하는 IPC의 실행은 커널 데몬에 메시지를 보내는 함수 int kerneld_send(int msgtype, int return_size, int msgsz, const char *text, const char *return_value); 에 의해서 확장되며, 다음 표와 같은 구조로 전송된다.

struct kerneld_msg {longmtype;longid;shortversion;shortpid;chartext[1];};

mtype 요소는 메시지를 담고 있고 id는 커널이 대답을 요구하는 지를 표시한다. id가 0이 아니라면 요구된 오퍼레이션의 종료 후에 커널 데몬은 mtype으로 id의 내용을 메시지로 보내고 새로운 id값으로 실행된 명령의 결과 값을 건네준다. pid 요소는 커널 요구를 일으키는 프로세스의 PID를 가진다. 커널 데몬은 환경변수의 KERNELD_TRIGGER로 시작하는 모든 프로그램에 모듈을 로드하고 해제하는 권한은 함수에 있다.

int request_module (const char *name);int release_module(const char *name, int wait_flag);int delayed_release_module(const char *name);int cancel_release module(const char *name);

커널은 request_module()로 모듈의 로딩을 요청하고 오퍼레이션이 수행될 때까지 기다린다. release_module()함수는 오퍼레이션의 종료가 기다려져야 하는지 지정하는 wait_flag로 모듈을 해제한다. delayed_release_module() 함수는 모듈이 지정한 대로 지연된 후 제거되게 한다. 이 함수는 오퍼레이션이 cancel_release_module()에 의해 제거되지 않았다면 60초 후에 자동으로 모듈을 제거하게 지시한다. 가령 예를 들어 파일 시스템 타입은 데이터 자원이 장착될 때를 발견할 수 없다면 커널이 다음 코드를 실행한다.

for ( fs = file_system; fs && strcmp(fs->name,name); fs = fs->next ) ;#ifdefCONFIG_KERNELDif ( !fs && ( request_module(name) == 0 ) ) {for ( fs = file_system; fs && strcmp( fx->name, name ); fs = fs->.next ) ;}#endif

이런 방식으로 알려지지 않은 파일 시스템은 모듈 이름이 파일 시스템 이름으로 확인될 때 언제나 로드된다. 장치 관리자에겐 일반적인 요청은 다음의 char-major-major이나 block-major-major패턴으로 생성된다. 커널 데몬은 모듈을 로딩하고 해제하는 요청을 modprobe-k로의 호출로 변환한다. 이 시스템 프로그램은 모듈의 이름에 일반적인 요청에서 로드되도록 할당할 수 있다. 그것은 리눅스 커널에서 사용되는 모든 커널 이름을 가지고 있다. 그래서 단지 새로운 모듈만이 파일 /etc/modules.conf나 /etc/conf.modules에 엔트리로 등록된다.

따라서, 본 발명은 리눅스 보안커널 모듈을 구현하는 것을 목적으로 한다.

리눅스 보안커널의 설계 목표는 관리의 어려움과 성능저하를 최소화하고 보안수준을 극대화하는 데 있다. 그리고 실제 리눅스 보안커널은 운영체제 수준에서 구현되고, 운영체제의 가상부분으로서 운영된다. 또한 이를 위해서 기존 운영체제 커널 코드를 새로 작성하거나 운영체제 커널을 새로 생성하지 않는다는 전제 조건 하에 개발되었다.

리눅스 보안커널의 기능은 다음 표와 같다.

기 능	세부기능
로긴 제어 기능	시간대별 로긴 접속 제한동일 사용자 중복 로긴 접속 제한동시 로긴 접속 최대 사용자수 제한미사용 로긴ID 검사 및 삭제root ID의 사용 제한사전 등록된 사용자만이 su를 통해서 root 권한 획득
파일 및 자원 접근 제어 기능	파일 접근 사용자 제한파일 접근 가능한 시간 제한
특정 명령어 및 프로세스 수행 제어 기능	특정 명령어 사용을 사용자별 제한특정 명령어 사용을 시간대별 제한suid, sgid 프로그램 제한
파일변질 여부 점검 기능	파일 변질 여부 확인
이벤트 발생 및 전달 기능	보안정책에 위배되는 접근이 있을때 이벤트 발생 및 전달
로깅 기능	root 권한 획득한 후에 모든 수행 내역을 로깅프로세스 종료(kill) 이력 로깅특정 명령어 수행 이력 로깅

도 2는 본 발명의 시스템에서 리눅스 보안커널의 위치 상호 연관을 나타내고 있다.

도 1과 같이 운영체제 커널에는 시스템호출에 대한 메모리 주소 포인터를 가지고 있는 시스템 벡터 테이블(system vector table)이 있다. 메모리 주소 포인터는 시스템 호출의 실제 커널 코드가 존재하는 메모리상의 위치를 가리킨다. 리눅스 보안커널 모듈(16)은 보안과 관련된 시스템 호출의 메모리 주소 포인터를 다른 곳에 저장한 후, 커널상에서 보안과 관련된 일을 수행할 별도의 시스템 호출의 메모리 주소를 대체한다.

따라서 사용자 프로세스(11)가 보안과 관련된 시스템 호출을 수행하게 되면, 리눅스 보안커널 모듈(16)은 원래의 해당 시스템 호출을 수행하는 것이 아니라 별도의 시스템 호출을 수행하게 되며, 별도의 시스템 호출은 보안정책 데이터베이스를 읽어 보안설정 사항에 위반되는가를 검사한다. 위반사항이 없을 경우에는 원래의 시스템 호출로 수행 흐름을 돌려주고, 위반사항이 있을 경우에는 곧바로 사용자에게 에러를 돌려준다.

도 1은 리눅스 보안 커널 개념도

도 2는 보안커널과 보안관리시스템 흐름도

도 3는 커널 모듈 수행 과정

도 4는 로긴 제어 기능 수행 과정

도 5는 파일 및 자원 접근 제어 기능 수행 과정

도 6은 특정 명령어 및 프로세스 수행 제어 기능 수행 과정

이하, 본 발명의 실시 예를 첨부된 도면을 참고하여 상세히 설명하면 다음과 같다.

도 3은 보안커널 모듈 수행과정 이다. 드라이버 초기화 시에 입력된 파라미터를 통해 최대 사용자수와 동일한 사용자에 대한 접속을 제한할 지를 결정하고, 수정한 system call로 system call table을 변경한다. 그리고 각 설정 파일들의 내용을 읽어들이고 버퍼에 저장한다. 설정 파일의 내용이 변경되었는지를 확인하기 위해 각각의 inode 번호를 읽어들인다.

정책구성파일은 /etc/nsl/chklogin, /etc/nsl/chkopen, /etc/nsl/chkexec로 구성되며, 로그파일은 /var/log/nsl/login.log, var/log/nsl/open.log, var/log/nsl/exec.log, var/log/nsl/root.log로 구성된다.

모듈 실행 방법은 각 정책 구성 파일을 생성한 후 내용을 입력한다. insmod 명령으로 모듈을 load한다.(insmod call.o umax=최대사용자수 identity=[y | n]) rmmod 명령으로 모듈 unload 한다.(rmmod call)

도 4는 로긴 제어 기능 수행 과정이다. 기존의 login(A11) 프로그램의 소스를 수정하여 ioctl()을 통하여 보안커널모듈(A13)로 정보를 전달한다. 첫 번째 ioctl() 호출은 사용자명을 보안커널모듈(A13)로 전달한다. 두 번째 ioctl()은 해당 사용자(A10)에 대한 접속 허용여부를 확인한다. 모듈(A13) 초기화 시에 읽어들인 구성 파일(etc/chklogin)의 사용자 필드와 현재 접속하려는 사용자(A10)의 ID를 비교하여, 만약 접속을 제한하려는 사용자(A10)와 동일하면 접속을 제한하는 시간대에 속하는지 확인하고, 제한시간에 포함된 경우는 해당 사용자의 login(A11)을 차단한다. 또한 동시 최대 사용자의 수를 제한하기 위해서 utmp(A15)파일을 사용한다. 이 파일은 시스템에서 제공되면 현재 접속한 사용자의 정보를 유지한다. 최대 접속자수가 넘어설 경우 이후의 접속을 차단한다. 동일한 사용자의 접속을 제한할 경우, utmp(A15)에서 사용자명 필드와 현재 접속하는 사용자의 ID를 비교하여 같은 사용자의 접속을 제한한다. 동시 최대 사용자수와 동일한 사용자의 접속 설정은 모듈(A13) load시 파라미터로 전달한다. 즉, 최대 사용자 수는 umax = xxx로, 동일한 사용자 접속 여부는 identity = y (예 : ismod call.o umax=300 identity=y)로 설정한다. 최대 접속자의 수는 300명으로 제한하고 동일한 사용자의 접속을 제한한다. 또한 로긴제어기능의 구성파일은 /etc/nsl/chkopen 으로 구성되며, 파일형식은 다음표와 같다.

#Username;접속제한시작시간;접속제한종료시간;# Comment.....................user1;0070;2400;user2;1400;2400;

위 표의 구성파일형식을 설명하면, Username은 사용자의 ID, 각 필드는 ";"로 구분하고, 제한 시간은 시와 분으로 구성(24시)한다. (예 : user1;0070;2400; user1이라는 사용자를 오전 7시부터 자정까지 접속을 제한)

도 5는 파일 및 자원 접근 제어 기능 수행 과정을 나타내는 것으로, open system call(B12)을 수정하고, 설정 파일(etc/nsl/chkopen)에 파일 접근을 제한할 UID와 제한 시간을 명시한다. 구성파일은 /etc/nsl/chkopen로 구성되며, 파일 형식은 다음 표와 같다.

#/Pathname/filenameUser-ID;제한시작시간;제한종료시간;# Comment...................../usr/local/apache/conf/httpd.conf510;0070;2400;/etc/hosts1011;1400;2400;

위 표의 파일형식을 설명하면, 첫 필드는 접근을 제한할 파일의 경로명이며, 파일명과 다음 필드는 Tab으로 구분하고, 나머지 필드는 ";"으로 구분한다. uid는 사용자의 uid이며, 제한 시작시간과 종료시간은 시와 분으로 구성된다. (예:/var/log/my.log 510;0000;2359; UID가 510인 사용자에 대해서 /var/log/my.log라는 파일에 대한 접근을 제한)

도 6은 특정 명령어 및 프로세스 수행 제어 기능 수행과정을 나타내는 것으로, execve system call(C11)을 수정하고, 설정 파일(etc/nsl/chkexec)에 실행을 제한할 프로그램명과 UID와 제한 시간을 명시 한다. suid 또는 sgid가 부여된 프로그램도 동일한 방법으로 설정 파일에 기록을 함으로써 제한이 가능하다. 즉, sui, sgid가 설정된 프로그램은 log 파일에 실행 내역을 기록) 구성파일은 /etc/nsl/chexec이며, 파일 형식은 다음 표와 같다.

#/Pathname/filenameUser-ID;제한시작시간;제한종료시간;# Comment...................../bin/su510;0070;2400;/bin/ps1011;1400;2400;

위 표의 파일형식을 설명하면, 실행을 제한할 프로그램의 경로명이고, 경로명과 다음 필드는 Tab으로 구분하며 다른 필드는 ";"으로 구분한다. 제한 시간과 종료 시간은 시와 분으로 구성한다.(예:/bin/su 520;0700;1800; UID가 520인 사용자에 대해서 su 명령을 아침 7시부터 오후 6시까지 제한)

로깅 기능의 로그파일에는 제한한 사용자의 접속시도를 기록하는 login.log와 특정 프로세스 또는 명령의 수행을 기록하는 exec.log 파일과 특정 파일의 접근에 대한 내역을 기록하는 open.log 파일, root 권한으로 실행한 내역을 기록하는 파일로 구성된다. 또한 수행한 명령 또는 프로세스 실행 여부를 UID와 함께 기록된다.

구성파일 Update기능은 각 설정 파일들의 내용을 변경했을 경우, 변경된 내용을 바로 적용할 수 있도록 write system call을 수정한다. 즉, 모듈 load시 각 설정 파일들의 inode 번호르 읽어들인 후 변경된 파일의 inode번호와 설정 파일의 inode번호가 일치할 경우 설정파일을 읽어들인 버퍼의 내용을 update 한다.

본 발명의 리눅스 보안커널 데이터 구조는 다음 표와 같다.

// 설정 파일을 읽어들일 버퍼static char *login_conf_buf, *exec_conf_buf, *open_conf_buf;// 설정 파일의 inode 번호를 저장int login_conf_inode_num, exec_conf_inode_num, open_conf_inode_num;static int cur_pos_login = 0, cur_pos_exec = 0, cur_pos_open = 0;// log 파일에 기록할 내용을 저장하는 버퍼char message[256];// 설정 파일의 각 필드를 저장할 구조체struct check_file_permit {char filename[64];// 파일명 또는 프로그램의 경로명char uid[8];// 사용자의 UIDchar s_time[5];// 제한할 시작 시간char e_time[5];// 제한할 종료 시간};// UTMP 파일을 읽어들이기 위한 구조체#define UT_LINESIZE32#define UT_NAMESIZE32#define UT_HOSTSIZE256struct mod_exit_status{short int e_termination;short int e_exit;};struct mod_utmp{short int ut_type;pid_t ut_pid;char ut_line[UT_LINESIZE];char ut_id[4];char ut_user[UT_NAMESIZE];char ut_host[UT_HOSTSIZE];struct mod_exit_status ut_exit;long int ut_session;struct timeval ut_tv;int32_t ut_addr_v6[4];char unused[20];};

본 발명의 함수별 기능은 다음 표와 같다.

int init_module()- 드라이버 초기 수행 함수.- system call을 변경.- 설정 파일의 내용과 inode 번호를 읽음.void cleanup_module()- 드라이버 unload 함수.- system call을 복원하고 할당한 메모리를 해제.int our_open(const char *pathname, int flags, mode_t mode)- open system call을 대체.- 파일 접근 제한 기능 수행.int our_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg)- ioctl system call을 대체.- login 제한 기능을 수행.size_t our_write(unsigned int fd, const char * buf, size_t count)- write system call을 대체.- 설정 파일의 내용이 변경되었을 경우, 파일의 내용을 저장하고 있는 버퍼의 내용을 갱신.int our_execve(struct pt_regs regs)- execve system call을 대체.- 프로세스의 실행 또는 제한하는 기능 수행.int get_file_size(char *filename)- input : filename -> 파일명.- 파일의 크기를 반환.char * getline(char *buf, int file_chk)- input : buf -> 설정 파일의 내용을 저장하고 있는 버퍼.file_chk -> 설정 파일을 구분하기 위한 실별자.- 설정 파일의 한 line을 반환.int max_user(char * username)- input : username -> 사용자 ID- 파라미터로 전달된 최대 사용자 수와 현재 접속한 사용자 수를 비교.- 동일한 사용자의 접속을 제한할 경우 같은 사용자의 접속 제한.- 현재 사용자수를 반환.- -1을 반환 할 경우 이미 동일한 사용자가 접속되어 있음을 의미.void get_permit_data(char *line, struct check_file_permit *t_permit)- input : line -> 설정 파일의 한 linet_permit -> line의 내용을 저장하기 위한 구조체- 입력된 문자열을 읽어서 구조체의 각 필드로 저장.int valid_check(char *filename, int size, int file_check)- input : filename -> open 또는 실행할 파일명.size -> 설정 파일의 크기.file_chk 설정 파일을 구분하기 위한 식별자.- 설정 파일에 저장된 내용과 현재 실행할 명령어 또는 open 할 파일명과 비교하여 현재사용자가 사용할 수 있는지를 판단.- 0을 반환하면 실행 제한.- 1을 반환하면 실행 허용.void read_config_file(char *filename, int file_check)- input : filename -> 설정 파일명.file_check -> 설정 파일을 구분하기 위한 식별자.- 설정 파일을 읽어서 버퍼에 저장.int print_log(char * filename, char * msg)- input : filename -> 저장할 log 파일명.msg -> log 파일에 기록할 내용을 저장하는 버퍼.char * get_time(void)- 현재 시간을 반환(hh:mm)

따라서 리눅스 보안커널 및 보안 관리 소프트웨어의 개발은 네트워크 보안 사고에 대한 원천적인 봉쇄로 인하여 시스템의 복구에 따른 경제적 시간적 비용을 절감할 수 있다. 또한 안전한 운영체제의 기술은 미국과 같은 선진국에 의해 주도되고 있는데 이 분야에서 우리 나라 자체 기술의 확보가 시급한 실정이다. 또한 본 과제에서 개발된 커널을 통한 보안 기술은 네트워크가 사용되는 모든 분야에 응용이 가능하다. 즉, Ftp서비스, 웹 서버, Finger 서비스, POP서버, NFS(Network File System) 등에 응용 가능하다.

전통적으로 군사 목적 및 정부기관의 중요 문서를 보호하기 위하여 적용되었던 안전한 운영체제 설계 및 구현은 TCSEC(Trusted Computer System Evaluation Criteria)의 요구사항을 적용하였다. TCSEC은 C1 (최하위 등급), C2, B1, B2, B3, A1(최상위 등급)의 6가지 등급을 가지며 각 등급별로 보안 요구 사항을 정의하고 있다. TCSEC의 요구사항에 맞게 구현된 시스템은 중요한 정보를 보호하였지만 시스템의 성능을 저하시키는 원인이 되기도 하였다. 최근 폭발적으로 증가하는 네트워크 사용 추세를 감안할 시 안전한 운영체제에 대한 필요성은 급증하였다. 그러므로 리눅스 보안커널 및 보안 관리 소프트웨어의 개발은 이러한 사용자의 요구사항을 바탕으로 한다.

선진국에서는 이러한 기술 개발을 통하여 핵심기술 확보에 경쟁적으로 연구를 진행하고 있다. 이러한 기술 확보는 커널 내부에서 보안 기능을 제공하는 것으로 선진 기술을 확보한다는 의미를 갖는다. 우리 나라도 이제 시작 단계인 리눅스 보안커널 및 보안 소프트웨어 개발에 핵심 기술들을 축적하고 개선하는 노력이 따르지 않을 경우 21세기 정보화 사회에 경쟁력을 가질 수 없다.

Claims

리눅스 시스템의 보안 사고방지와 해결을 위하여 응용프로그램 레벨이 아닌 리눅스 운영체제 커널 부분에서 구현하는데 있어서, 커널로 들어오는 시스템 콜(system call)을 가로채어 해당 시스템 콜에 필요한 기능을 추가하고 기록된 로그 파일을 이용하여 실시간 모니터링 및 감사는 응용프로그램에서 처리함으로서 사용자 인증으로 내외부 사용자의 오남용으로 인한 손상을 방지하고, 내외부 사용자가 파일을 손상하거나 변질 방지를 제공하도록 함을 특징으로 하는 리눅스 보안커널.