Security goals of OS
전통적으로 컴퓨터는 Time-sharing에 초점을 맞췄고 그에 따라 separation과 sharing이 주요 기능으로 사용되었다. 그러나 모든 user가 terminal에 접근이 가능함에 따라서 보안 문제가 발생하였다. 이를 해결하고자 다음의 solution을 제안했다.
- User authentication
- Processor mode
- Memory protection
- File access control
최근에는 컴퓨터가 network로 이어지게 됨에 따라 새로운 threat이 등장한다. Network를 사용하는 program의 buggy나 감염 등의 문제가 발생하였다. 이를 해결하고자 다음의 solution을 제안했다.
- Access control
- Secure communication
- Logging, Auditing
- Intrusion prevention and detection
- Recovery
현재, 미래에는 Mobile, embedded computing device가 사용되거나 될 것이며 그에 따른 새로운 위협이 등장한다. 장치에 개인정보가 증가함에 따른 유출 위험도 등의 문제가 발생한다. 이를 위한 solution은 다음과 같다.
- App vetting
- Isolation of each app
- Help users access risks of app
- Risk management / communication
Computer System Components
| Hardware | Operating System | Applications / Programs |
User |
| basic computing resource | control HW | How to use OS | Us |
Memory Protection
Memory access를 control한다. 핵심은 하나의 process가 다른 process의 memory를 access 하지 못하는 것이다. 이를 위해서는 OS와 process가 다른 priviledge를 가져야 한다.
CPU mode
Kenel mode라고도 한다. OS의 권한을 의미하며, 자원과 process의 state를 제약 없이 사용 및 조작할 수 있다.
- Execute any instruction
- Access any memory loaction
- Access MMU(memory management unit)
- ...
User mode
Kernel mode와 다르게 제약을 가진다. Memory 접근, instruction 실행, interrupt 발생 등 여러 부분에서 제약을 받는다.
Q. 제약을 풀고 어떤 일을 수행하고 싶으면 어떻게 해요?
System call을 이용해서 kernel에게 업무를 부탁하면 된다.
System call
User mode에서 kernel mode 수준의 작업이 필요한 경우, system call을 사용하여 작업을 해결할 수 있다. System call의 과정은 다음과 같이 진행된다.
- User mode에서 special CPU inst.를 수행한다. Interrupt이라고도 한다.
(syscall, 0x80, ...) - Store user state & change state form user to kernel
- Do kernel work
- Restore user state & return user mode
Kernel space & User space
Priviledge levels
Priviledge level이 필요한 이유는 보안 때문이다. 만약 attack과 defense가 같은 level이라면, 항상 defense를 보장할 수 없게 된다. 그러나 higher priviledge를 가지고 있으면, isolation이 가능해서 defense를 보장할 수 있게 된다.
Access control
Reference monitor가 process의 모든 access를 감시하고 control한다. "Complete mediation"이라고도 한다.
Access model matrix
Subject가 Object에 어떤 Right를 가지는 지 정리한 표이다.
- Subject
Object에 접근하는 entity - Principal
Unit of access control and authoriazation
User account의 보안 수준이라고 보면 된다. - Object
Files, Directories, Memory segments 등
Subject도 object가 될 수 있다. ex) kill
Basic concepts of UNIX access control
User, Group, File, Process
- User는 uid를 가진다.
UID 0 : root - Subject는 process이다.
- Object는 file이다.
Group은 principal이 될 수 있다.
Users & Principals
User는 system에 의해서 여러 principal을 가질 수 있다. 이는 accountability를 보장한다.
Organization of Objects
UNIX에서 모든 object는 file-directory로 관리된다. 각 object는 owner, group, 12 permission bits을 가진다. Permission bit는 다음과 같이 구성된다.
- Owner : rwx
- Group : rwx
- Others : rwx
- suid, sgid, sticky
UNIX iNodes
File 접근을 효율적으로 관리하기 위해서 iNode를 사용한다.
iNode를 보고 File에 접근하면, access 수를 줄일 수 있다.
Permission bit ; File
rwx가 있다.
- r : read 가능
- w : write 가능
- x : execute 가능
Permission bit ; Directory
File에서와 비슷하지만 조금 다르다.
- r : Directory 내 file name을 보여준다.
- x : Directory 접근이 가능하며, 내부 file을 실행할 수 있다.
- w+x : create, delete, rename이 가능하다.
path에 있는 모든 directory의 permission bit가 x여야 원하는 file에 접근할 수 있다.
ex) Directory r-- 이면?
file name 확인 가능, file 실행은 불가능
ex) Directory --x 이면?
file name 확인 불가능, file 실행은 가능
ex) access directory/file ?
read : /d1 /d2 /f1
- d1 : --x
- d2 : --x
- f1 : r--
write : /d1 /d2 /f1
- d1 : --x
- d2 : --x
- f1 : -wx
delete : /d1 /d2 /f1
- d1 : --x
- d2 : -wx
- f1 :
rename : /d1 /d2 /f1
- d1 : --x
- d2 : -wx
- f1 :
The suid, sgid, sticky bit
- suid
set euid, file 소유자의 권한을 줄 수 있다. - sgid
- sticky
owner만 directory delete/modify 가능하다.
Negative Authorization?
"특정 group의 member는 접근할 수 없다"
구현할 수 있지만 권장하지 않는다. 관리에 용이하지 않기 때문이다.
Other issues on Objects in UNIX
Permission bit 수정 가능한 사람 : owner
Owner 변경 가능한 사람 : super user
Rights는 file에 의해서 결정되지 않는다. Super user가 정하는 것이다.
Security Principles Related to Access control
3가지가 있다.
- Complete mediation : 모든 access 검사
- Fail-safe defaults : 일단 deny
- Least priviledge : 최대한 낮은 권한으로 시작하기
Principle of Complete Mediation
모든 access의 authority를 검증한다. 이 과정에서 access control은 외부에 의해서 변하지 않아야 한다.
*violated
- OS kernel 감염처럼 Protection scheme이 올바르게 작동하지 않는 경우
- Access control이 bypassed 당하는 경우 (file system 없이 disk 접근 등)
Principle of Fail-Safe defaults
Default configuration : No access allowed
어떤 상황에서 access에 permission을 줄 지 결정하는 것이 더 올바른 보안 방법이다. Whitelist나 Fire wall는 대표적인 fail-safe default이다.
*violated
Guest account의 high priviledge
Principle of Least Privilege
System의 모든 program과 user는 least priviledge를 가지고 operate한다. 이렇게 함으로써, accident나 error에서 발생하는 피해를 줄일 수 있다.
Process user ID model in Moder UNIX
Principal을 쉽게 관리하기 위하여 process ID를 사용한다. Process는 3개의 user ID와 3개의 group ID를 가진다.
| ruid real user ID |
process의 owner이다. |
| euid effective user ID |
실제로 접근을 control할 때, 확인하는 ID이다. |
| suid saved user ID |
일시적인 권한 drop을 위해 ruid를 저장한다. |
| rgid, egid, sgid | group에 대해 같은 id이다. |
*Process creation과 execution시 어떤 priviledge를 사용할까?
사용가능 후보는 file의 owner와 process의 owner가 있다. 상황에 따라 다르게 설정된다.
- Process → fork()
부모 process의 uid를 상속한다. - Process → exec()
file의 suid가 설정되면, file의 owner의 uid를 euid, suid로 사용한다.
(suid, set user id)
그렇지 않으면, process의 uid를 사용한다.
suid(sgid) bit의 필요성과 문제점
몇 operation이 user id=0을 요구하기 때문에 필요하다. 또한 file level access control은 충분히 잘 동작하지 않는다. System integrity는 누가 wirte할 수 있는지 관리하는 것 보다는 어떻게 write 되었는 지가 더 중요하기 때문이다.
일반적으로 suid = root를 요구한다. 하지만 이는 Least priviledge를 위반하게 된다. 또한 attack의 가능성이 있다. 따라서 이를 관리하기 위하여 euid, effective user id가 사용된다.
Changing effective user ID
영구적인 priviledge drop과 일시적인 priviledge drop이 있다. 이에 따라 다르게 설정된다.
- Drop priviledge permanently
setuid(ruid) = euid
saveuid(ruid) = suid - Drop priviledge temporarily
setuid(ruid) = euid
saveuid(0, root) = suid
What happens during Logging In
User가 로그인해서 비밀번호를 변경하는 과정이다.
'Study > Computer Security' 카테고리의 다른 글
| 6. Web security (0) | 2023.04.17 |
|---|---|
| 5. Key distribution & Aggrement, Secure communication (0) | 2023.04.17 |
| 3. Authentication (0) | 2023.04.13 |
| 2. Cryptography (0) | 2023.04.11 |
| 1. Cryptography (0) | 2023.04.10 |