[Linux] Capabilities

(Traditional) superuser and set-UID-root programs

• 전통적인 유닉스 권한 모델은 사용자를 두 그룹으로 나눈다
  
  • 일반 유저(Normal users): UID, GID 기반으로 권한 검사 대상
  • 슈퍼 유저(Super user(UID = 0)): 일련의 검사를 우회(bypass)
• 권한이 없는 사용자에게 권한을 부여하는 전통적인 메커니즘은 `set-UID-root` 프로그램이다.

# chown root prog
# chmod u+s prog

• `set-UID-root`프로그램이 실행되면, 프로세스는 파일 소유자의 UID로 가정한다. 즉, 프로세스는 슈퍼 유저의 권한을 얻는다.
• 이러한 방식은 효과적일 수 있지만 위험한 방법이기도 하다.

The traditional privilege model is a problem

• 전통적인 권한 모델의 거친 모양(granularity)이 문제다
  
  • 프로그램에 시스템 시간을 바꿀 수 있는 능력을 주고 싶다면?
    
    • 모든 것을 할 수 있는 능력(루트가 할 수 있는)을 주어야 한다
  • 만일 프로그램이 손상된다면 피해가 무지막지함(="No limit on possible damage")
• `Capabilities`가 이러한 문제를 풀기 위한 시도(attempt)이다.

Background capabilities(1/2)

• `Capabilities`: 슈퍼 유저의 힘을 작은 조각으로 나눈 것
  • 리눅스 5.2 버전에 총 38개의 `capabilities`가 있음(see `capabilities(7)`)
  • 예제
    • `CAP_DAC_OVERRIDE`: 모든 파일 권한 체크를 우회함
    • `CAP_SYS_ADMIN`: 많은 `sysadmin`작업을 수행
    • `CAP_SYS_TIME`: 시스템 시간 변경
• `set-UID-root`프로그램 대신 하나 또는 몇 개의 `capabilities`가 부착된 프로그램이 있다
  
  • `setcap(8)`을 이용하여 `capabilities`를 부착한다(`CAP_SETFCAP` capability가 필요함)
  • 프로그램이 실행되면, 프로세스는 부착한 `capabilities`를 얻는다
  • `set-UID-root`프로그램보다 `capabilities`가 부착된 프로그램이 더 약하다(weaker)
    
    • 약하다: 프로그램이 손상된다면 ( `set-UID-root`프로그램이 손상된 것보단) 덜 위험하다.

Background capabilities(2/2)

• 요약
  • 프로세스는 `capabilities`를 가질 수 있다(루트(root) 힘의 서브셋(subset)).
  • 파일은 프로그램을 실행하는 프로세스에 주어진 부착된 `capabilities`를 가질 수 있다.
  • `capabilities`를 사용하는 권한을 가진 바이너리/프로세스는 손상될 경우 덜 위험하다.

 

---

참고할만한 글

chmod u+s prog
// +s에 대한 내용 찾다가 발견한 글

set-user-id or set-group-id

If the s group of permissions has the user bit set (corresponding to u+s), then whenever anyone executes that program, the process takes on the privileges of whoever owns it. If root owns a file that's marked u+s and o+x (everyone can execute it), then the file is called "suid root" -- whenever anyone runs it, the program gets full root privileges. This can be a security hole if improper care is given to securing the program itself.

The most widely-used reason for doing this is probably the su binary. In order to become another user, the process that's running needs to have root privileges (according to the manpage in section 2 for setuid, that is). So normal users can't run a program that changes the current UID -- this means that normally, no one would be able to use su except for root, which is obviously not good.

So you make root own the /bin/su program, and make it world executable (or in my case, group executable and then add only users that I wish to be able to become root to the appropriate group), so that when a user starts it up, it begins life with root's privileges. It can then switch UID's to anything it wants, subject to the program checking passwords.

Use of the g+s bit is similar -- but here, you're giving whoever can execute the program privileges of a certain group. I don't think I've ever seen this actually used, except for on directories. If that bit is set on a directory, then whichever group owns the directory will also own any files created inside that directory -- but this is a special extension that not all filesystems have to honor. The vast majority do (and I believe that POSIX also prescribes this, but I'm not sure), though.