Linux Security Modules: 일반 보안 hook

문서 상태와 저자

이 문서는 Linux Security Modules의 일반 보안 hook을 설명하는 Stephen Smalley, Timothy Fraser, Chris Vance의 기술 문서다. 문서 자체가 여기서 설명하는 API가 오래되었다고 명시하므로, 실제 개발에서는 현재 `security/security.c`와 최신 LSM 문서를 우선해야 한다.

========================================================
Linux Security Modules: General Security Hooks for Linux
========================================================

:Author: Stephen Smalley
:Author: Timothy Fraser
:Author: Chris Vance

.. note::

   The APIs described in this book are outdated.

SELinux에서 일반 보안 프레임워크로

2001년 3월 NSA는 Linux 2.5 Kernel Summit에서 SELinux를 발표했다. SELinux는 유연하고 세밀한 비재량적 접근 제어를 Linux 커널에 구현했지만 처음에는 독립 커널 patch였다. RSBAC과 Medusa 같은 다른 보안 프로젝트도 접근 제어 구조를 만들었고, LIDS, DTE, SubDomain 같은 프로젝트도 고유 모델을 위해 각자 patch를 유지했다.

발표 뒤 Linus Torvalds는 mainline에 포함할 수 있는 일반 프레임워크의 조건을 제시했다. 커널 객체 연산을 통제하는 security hook 집합과 보안 속성을 보관하는 커널 자료구조의 opaque security field를 제공하고, loadable module이 원하는 보안 모델을 구현하게 하는 구상이었다. Linux capabilities 코드도 이러한 module로 옮길 수 있다고 제안했다.

WireX가 이 구상을 구현하기 위해 LSM 프로젝트를 시작했다. Immunix, SELinux, SGI, Janus와 Greg Kroah-Hartman, James Morris를 포함한 여러 개인이 공동으로 개발했으며 2003년 12월 mainline에 포함되었다. 이 보고서는 그 프레임워크와 capabilities 보안 module의 개요를 제공한다.

Introduction
============

In March 2001, the National Security Agency (NSA) gave a presentation
about Security-Enhanced Linux (SELinux) at the 2.5 Linux Kernel Summit.
SELinux is an implementation of flexible and fine-grained
nondiscretionary access controls in the Linux kernel, originally
implemented as its own particular kernel patch. Several other security
projects (e.g. RSBAC, Medusa) have also developed flexible access
control architectures for the Linux kernel, and various projects have
developed particular access control models for Linux (e.g. LIDS, DTE,
SubDomain). Each project has developed and maintained its own kernel
patch to support its security needs.

In response to the NSA presentation, Linus Torvalds made a set of
remarks that described a security framework he would be willing to
consider for inclusion in the mainstream Linux kernel. He described a
general framework that would provide a set of security hooks to control
operations on kernel objects and a set of opaque security fields in
kernel data structures for maintaining security attributes. This
framework could then be used by loadable kernel modules to implement any
desired model of security. Linus also suggested the possibility of
migrating the Linux capabilities code into such a module.

The Linux Security Modules (LSM) project was started by WireX to develop
such a framework. LSM was a joint development effort by several security
projects, including Immunix, SELinux, SGI and Janus, and several
individuals, including Greg Kroah-Hartman and James Morris, to develop a
Linux kernel patch that implements this framework. The work was
incorporated in the mainstream in December of 2003. This technical
report provides an overview of the framework and the capabilities
security module.

LSM 프레임워크의 역할

LSM은 security module을 지원하는 일반 커널 기반 구조이며 주된 초점은 접근 제어 module이다. 향후 sandboxing 같은 다른 보안 요구도 다룰 수 있지만, 프레임워크 자체가 추가 보안을 제공하는 것은 아니고 module을 위한 인프라만 제공한다. 이 기능은 선택 사항으로 `CONFIG_SECURITY`를 켜야 하며 capabilities 로직도 security module로 구현된다.

프레임워크는 커널 자료구조에 security field를 넣고 커널 코드의 중요한 지점에서 hook 함수를 호출해 field를 관리하고 접근 제어를 수행한다. security module 등록 함수도 제공한다. `/sys/kernel/security/lsm`은 현재 활성화된 security module을 쉼표로 구분해 보여 준다.

LSM Framework
=============

The LSM framework provides a general kernel framework to support
security modules. In particular, the LSM framework is primarily focused
on supporting access control modules, although future development is
likely to address other security needs such as sandboxing. By itself, the
framework does not provide any additional security; it merely provides
the infrastructure to support security modules. The LSM framework is
optional, requiring `CONFIG_SECURITY` to be enabled. The capabilities
logic is implemented as a security module.
This capabilities module is discussed further in
`LSM Capabilities Module`_.

The LSM framework includes security fields in kernel data structures and
calls to hook functions at critical points in the kernel code to
manage the security fields and to perform access control.
It also adds functions for registering security modules.
An interface `/sys/kernel/security/lsm` reports a comma separated list
of security modules that are active on the system.

Security blob과 hook stacking

LSM security field는 `void *` pointer이며 그 데이터는 blob이라고 부른다. blob은 프레임워크 또는 사용하는 개별 security module이 관리할 수 있고, 여러 module이 공유하는 blob은 보통 프레임워크가 관리한다.

프로세스와 프로그램 실행 정보는 `struct task_struct`와 `struct cred`, 파일시스템 정보는 `struct super_block`, pipe·file·socket 정보는 `struct inode`와 `struct file`에 둔다. System V IPC 정보는 `struct kern_ipc_perm`과 `struct msg_msg`에 field를 추가했고, module이 정의를 사용할 수 있도록 `struct msg_msg`, `struct msg_queue`, `struct shmid_kernel` 정의를 적절히 `include/linux/msg.h`와 `include/linux/shm.h`로 옮겼다.

packet과 network device 보안 정보는 `struct sk_buff`와 `struct scm_cookie`에 32비트 정수로 저장한다. 다른 LSM 데이터와 달리 pointer가 아니므로 module은 이 값을 실제 보안 속성에 매핑하거나 연관시켜야 한다.

각 LSM hook은 목록으로 관리되고 `CONFIG_LSM`에 지정된 순서대로 호출된다. module은 `security_add_hooks()`에 `struct security_hooks_list`를 전달해 hook 목록에 추가한다. 일반적인 stacking에 가까운 동작을 제공하지만 등록된 hook을 제거하는 프레임워크 메커니즘은 없다. SELinux의 자체 제거 기능은 존재했으나 폐기 예정으로 바뀌었다.

The LSM security fields are simply ``void*`` pointers.
The data is referred to as a blob, which may be managed by
the framework or by the individual security modules that use it.
Security blobs that are used by more than one security module are
typically managed by the framework.
For process and
program execution security information, security fields are included in
:c:type:`struct task_struct <task_struct>` and
:c:type:`struct cred <cred>`.
For filesystem
security information, a security field is included in :c:type:`struct
super_block <super_block>`. For pipe, file, and socket security
information, security fields are included in :c:type:`struct inode
<inode>` and :c:type:`struct file <file>`.
For System V IPC security information,
security fields were added to :c:type:`struct kern_ipc_perm
<kern_ipc_perm>` and :c:type:`struct msg_msg
<msg_msg>`; additionally, the definitions for :c:type:`struct
msg_msg <msg_msg>`, struct msg_queue, and struct shmid_kernel
were moved to header files (``include/linux/msg.h`` and
``include/linux/shm.h`` as appropriate) to allow the security modules to
use these definitions.

For packet and
network device security information, security fields were added to
:c:type:`struct sk_buff <sk_buff>` and
:c:type:`struct scm_cookie <scm_cookie>`.
Unlike the other security module data, the data used here is a
32-bit integer. The security modules are required to map or otherwise
associate these values with real security attributes.

LSM hooks are maintained in lists. A list is maintained for each
hook, and the hooks are called in the order specified by CONFIG_LSM.
Detailed documentation for each hook is
included in the `security/security.c` source file.

The LSM framework provides for a close approximation of
general security module stacking. It defines
security_add_hooks() to which each security module passes a
:c:type:`struct security_hooks_list <security_hooks_list>`,
which are added to the lists.
The LSM framework does not provide a mechanism for removing hooks that
have been registered. The SELinux security module has implemented
a way to remove itself, however the feature has been deprecated.

Hook 범주와 capabilities module

hook은 크게 security field를 관리하는 hook과 접근 제어를 수행하는 hook으로 나뉜다. `security_inode_alloc()`과 `security_inode_free()`는 inode 객체의 security 구조를 할당하고 해제하는 첫 범주의 예다. `security_inode_permission()`은 inode 접근 시 권한을 검사하는 두 번째 범주의 예다.

POSIX.1e capabilities 로직은 `security/commoncap.c`의 security module로 유지된다. capabilities module은 `lsm_info` 설명의 order field를 사용해 가장 먼저 등록되는 security module임을 나타낸다. 다른 module과 달리 일반 security blob을 사용하지 않는데, 이는 overhead, 복잡성, 성능에 관한 역사적 이유 때문이다.

The hooks can be viewed as falling into two major
categories: hooks that are used to manage the security fields and hooks
that are used to perform access control. Examples of the first category
of hooks include the security_inode_alloc() and security_inode_free()
These hooks are used to allocate
and free security structures for inode objects.
An example of the second category of hooks
is the security_inode_permission() hook.
This hook checks permission when accessing an inode.

LSM Capabilities Module
=======================

The POSIX.1e capabilities logic is maintained as a security module
stored in the file ``security/commoncap.c``. The capabilities
module uses the order field of the :c:type:`lsm_info` description
to identify it as the first security module to be registered.
The capabilities security module does not use the general security
blobs, unlike other modules. The reasons are historical and are
based on overhead, complexity and performance concerns.