Chap 14 Access control Mechanism

Presentation on theme: "Chap 14 Access control Mechanism"— Presentation transcript:

1 Chap 14 Access control Mechanism
DB LAB 이용우

2 ACL Default Permisions Actual Implementation ACL Modification
Privileged Users Groups and Wildcards Conflicts Default Permission Revocation of Rights Windows NT Access Contol List

3 ACL:Access control List
Each column represents control ACL File : { (user1, rx), (user2, rwx), (user3, rx) } File2: { (user1, r), (user2, r), (user3, rw) } File3: { (user1, rw), (user3, w) } file1 file2 file3 User 1 rx r rw User 2 rwx User 3 W 만약 subject와 object의 Matrix를 통해 접근제어를 할 경우 요소들의 수가 증가하면 기하급수적으로 크기가 증가할 것이고 대부분의 경우 빈칸이거나 같은 칸을 가지고 있을 것입니다. 그리고 이러한 문제를 고려하면서 관리하기 위한 프로그램의 complexity도 증가할 것이다. 따라서 이를 해결하기 위한 방법 중 하나가 ACL이라고 할 수 있다. 기본적으로 access control model의 경우 ACL을 가지고 있다. ACL은 사용자인 subject와 right의 조합들의 set이라고 할 수 있다. 예를 들어보면 다음과 같다

4 Default Permissions Normal
If not named, no rights over file Principle of Fail-Safe Defaults If many subjects, may use groups or wildcards in ACL UNICOS: entries are (user, group, rights) If user is in group, has rights over file ‘*’ is wildcard for user, group (holly, *, r): holly can read file regardless of her group (*, gleep, w): anyone in group gleep can write file 다음으로 앞에서 말한 각종 작업들에 대한 permission들 중에서 default permission에 대해 설명하겠습니다. permission에 대해서 기본적으로 subject가 unnamed일 경우 모든 파일에 대해 권리를 갖지 못 하게 됩니다. 이는 fail-safe defaults 원리에 따라 아니다 싶으면 무조건 막아서 위험요소를 제거하는 원리라고 할 수 있습니다. 그리고 많은 subject들이 하나의 object에 대해서 권한을 가지고 있을 경우 group이나 wildcard를 통해 정의할 수 있습니다. 사용자가 그룹에 속해 있으면 해당 그룹이 갖는 모든 권한들이 사용자들에게 같이 적용되고 와이들 카드의 경우 특정 유저나 그룹일 경우 무조건 권한을 부여한다는 것입니다. 예를 들어 보면 다음과 같이 볼 수 있습니다.

5 Abbreviations ACLs can be long – so combine users
UNIX – 3 classes of users; owner, group, rest Ownership assigned based on creating process Unix환경에서 기본적으로 제공하는 접근제어는 다음과 같습니다. 3개의 class로 분류하여 각 3가지 경우에 따른 read, write, excution 이렇게 가지의 권리의 허용여부를 결정할 수 있습니다. 그리고 기본적으로 group owner ship을 포함한 모든 ownership은 처음 프로세스가 시작 될때 할당하게 구성되어 있습니다. 사실 이렇게 할 경우 적절하지 않은 경우가 많이 발생하고 group의 flexibility도 떨어지게 됩니다.

6 Actual Implementation
IBM’s version of the UNIX operation system(AIX) The specific algorithm Determine what set S of permissions the user has from the base permissions. If extended permissions are disabled, stop. The set S is the user's set of permissions. Get the next entry in the extended permissions. If there are no more, stop. The set S is the user's set of permissions. If the entry has the same user and group as the process requesting access, determine if the entry denies access. If so, stop. Access is denied. Modify S as dictated by the permissions in the entry. Go to 3. 따라서 앞서 말한 모델의 제약들을 완화하기 위해서 IBM에서 확장된 permission을 제고하는 시스템인 AIX를 개발하였습니다. 이는 전 모델과 다르게 user set으로부터 permission을 수정/삭제할 수 있도록 하고 있습니다. 이 모델을 permission의 결정은 다음과 같은 알고리즘으로 수행됩니다. 기본적인 permission들에서 user가 가지는 permission들의 set을 골라내고 확장된 permission이 있는지 확인하고 없을 경우 해당 permission set을 사용자의 permission set으로 지정을 합니다. 그리고 확장된 permission이 있으면 entry를 추가, 없는지 확인하고 더 이상 확장할 permission이 없으면 멈추고 S를 permission set으로 결정 만약 같은 사용자 그리고 그룹의 충돌이 있을 경우 deny할 것인지 결정합니다. 해당 permission을 추가한 entry의 수정을 하고 3번부터 다시 시작합니다.

7 Actual Implementation
Actual Example

8 ACL Modification Who does this?
Creator is given own right that allows this System R provides a grant modifier (like a copy flag) allowing a right to be transferred, so ownership not needed Transferring right to another modifies ACL 처음 데이터를 만들거나 새로운 ACL을 만들경우 처음 만든 사람 또는 proceessor가 소유자 권한을 가질 수 있습니다. 그리고 이 own right를 가진 사람이 해당 object에 대한 modification을 할 수 있습니다. 하지만 몇몇 시스템은 이와 다르게 다른 사람에게 이러한 권한을 부여할 수 있습니다. 예를 들어 Relation database system인 system R의 경우 프로세서나 허가된 사용자에 의해 수정할 수 있는 권한을 줄 수가 있고 이러한 권한을 grant option을 가진다고 할 수 있습니다. 이러한 방식을 통해 ownership을 통한 수정권한을 결정하는 것이 아니라 허가된 프로세서나 사용자에 의해 수정권한을 부여할 수 있습니다.

9 Privileged Users Do ACLs apply to privileged users (root) ?
Solaris: abbreviated lists do not, but full-blown ACL entries do Other vendors: varies 그리고 많은 시스템들이 privileged user를 가지고 있습니다. 가장 잘 알려진 것이 UNIX 시스템에서 root super-user와 윈도우 NT버전이나 2000 계열에서의 관리자가 있습니다. 이러한 privileged user는 ACL에 적용하는 것이 제한되어 있는데 예를 들어 solaris UNIX 시스템의 경우 두가지 기준을 사용하는데 하나는 abbreviation ACL과 full blown ACL이 있는데 전자의 경우 root인 subject는 무시하고 full-blown ACL의 경우 해당 subject를 이것이 root더라도 ACL entry에 포함시키게 됩니다. 그 외에도 다양한 방법이 있다고 볼 수 있습니다.

10 Groups and Wildcards Classic form: no; in practice, usually
AIX: base perms gave group sys read only Permit -w- u: heidi, g=sys Line above adds write permission for heidi when in that group UNICOS: holly: gleep: r –User holly in group gleep can read file holly: * : r –User holly in any group can read file *: gleep: r –Any user in group gleep can read file 그렇다면 이러한 ACL의 경우 group과 wildcard는 어떻게 처리할 것인가?에 대해 알아보겠습니다. 기본적으로 classic form의 경우 이 두가지 모두 허용하지 않고 있습니다. 하지만 실제적으로 시스템에서는 ACL의 크기를 조절하고 만들기 쉽게 하기 위해 1가지만 사용하거나 2가지 모두 사용하고 있습니다. 책에 나온 예를 보면 AIX의 경우 기본적으로 형성된 group sys의 경우 사용자들은 read만 할 수 있게 설정된다. 그리고 새롭게 permission을 줌으로써 다른 사용자가 write할 수 있게 할 수 있습니다. 위의 예를 보면 하이디에게 group id를 sys를 가진 경우 write까지 허용하게 되는 것을 볼 수 있습니다. 또 다른 예인 UNICOS를 보면 group의 경우 AIX와 유사하지만 이 시스템은 wildcard를 사용할 수 있습니다. 이에 따른 아래의 예를 들 수 있습니다.

11 Conflicts AIX: if any entry denies access, regardless or rights given so far, access is denied. Cisco routers: run packet through access control rules (ACL entries) in order; on a match, stop, and forward the packet; if no matches, deny Note default is deny so honors principle of fail-safe defaults 접근제어 모델은 사용하기 위해서는 conflict에 대한 문제도 해결해야 합니다. 하나의 object에 대해 다른 right가 주어진 경우 예를 들어 한명이 조건에 따라 read와 write에 대한 권한이 다른 경우가 발생하는데 subject에게 권한을 주느냐 혹은 거부하는가에 대한 결정이 필요하고 시스템 구현시 반드시 고려해야 합니다. 기존 구현된 모델의 예를 들어보면 먼저 AIX의 경우 ACL에 어떤 entry라도 deny된다면 다른 entry에 상관없이 access를 deny하게 됩니다. Cisco router의 경우 ACL의 순서에 따라 권한을 부여하게 됩니다. 들어온 packet에 대해서 match되는 entry가 있을 경우 허용을 하고 그렇지 않을 경우 deny하게 됩니다.

12 Default Permission Apply ACL entry, and if none use defaults
Cisco router: apply matching access control rule, if any; otherwise, use default rule (deny) Augment defaults with those in the appropriate ACL entry AIX: extended permissions augment base permissions 많은 UNIX 시스템은 ACL과 abbreviation ACL과 default permission이 3가지가 같이 사용되는 데 실제 접근제어를 하기 위한 2가지 방법이 있습니다. 첫 번째는 적절한 ACL entry가 있다면 이를 적용하여 접근권한을 주고 그 외의 경우에는 abbreviation ACL과 default permission를 적용하는 방법이 있고 두번째는 abbreviation ACL과 default permission의 비중을 늘려 사용하는 방법이 있습니다. 예를 들어 Cisco router의 경우 맞는 access control rule이 없을 경우 다시 말해 적용되는 ACL entry가 없을 경우 해당 packet을 폐기합니다. 이 방법은 말씀드린 두번째 방법이 되겠고 첫번째 방법은 AIX에서 기본적인 permission을 수정할 수 있으므로 첫번째 경우에 해당합니다.

13 Revocation of Rights How can we remove subject’s rights to a file?
Owner deletes subject’s entries from ACL, or rights from subject’s entry in ACL What if ownership not involved? Depends on system System R: restore protection state to what it was before right was given May mean deleting descendent rights too.. 접근 권한에 대한 revocation의 경우는 object의 ACL에서 해당 subject의 entry를 제거하거나, ACL에서 subject entry에서 권한을 제거함으로써 수행할 수 있습니다. 따라서 만약에 ownership을 가진 subject가 이를 제어하지 않는 다면 더욱 복잡해질 것입니다. 만약 이러한 경우가 발생할 수 있기 때문에 System R 에서는 어떻게 권한들이 주어졌는지 기록되어 있는 protection state를 둠으로 해서 이를 해결하고 있습니다.

14 Revocation of Rights Example(AIX)
애나 -> 피터 읽기 권한을 10이라는 시간에 주었고 피터가 매리에게 20이라는 시간에 권한을 주었을 때 애나가 perter의 권한을 revocation 한다면 매리의 권한도 사라집니다. 반대의 경우는 다음과 같습니다.

15 Windows NT Access Control List
Different sets of rights Basic: read, write, execute, delete, change permission, take ownership Generic: no access, read (r/x), change(r/w/x/d), full control(all), special access (assign any of the basics) Directory: no access, read (r/x in directory), list, add, add&read, change(create, add, r/w/x files; delete subdirectories), full control, special access 우리가 흔히 server에서 사용을 하는 window NT 계열의 경우 다음과 같은 ACL을 가지고 있습니다. 기본적으로 읽기, 쓰기, 실행, 삭제, 권한 변경, 소유권 변경 등을 할 수 있습니다. 그리고 이러한 기본적인 기능은 generic right set에 포함되어 있습니다. 다음과 같은 기능을 할 수 있고 이러한 권한들은 directory에도 적용될 수 있는데 다음과 같이 사용할 수 있습니다.

16 Capabilities Implementation Copying and Amplifying
Comparison with Access Control

17 Capabilities Each row represents control C-Lists:
User1: { (file1, rx), (file2, r), (file3, rw) } User2: { (file1, rwx), (file2, r) } User3: { (file1, rx), (file2, rw), (file3, w) } 앞에서 설명한 ACL과 반대의 개념이라고 할 수 있습니다. ACL이 어떤 파일에 대해 어떤 사용자가 접근할 수 있는가에 대한 개념이었다면 케이퍼빌리티는 사용자가 어떤 파일에 어떤 작업의 허가를 받았는지에 대한 개념입니다 예를 들어 보면 다음과 같습니다.

18 Implementation Tagged architecture Paging/segmentation protections
Associated with each hardware word Paging/segmentation protections Like tags, but put capabilities in a read-only segment or page CAP system did this Programs must refer to them by pointers Otherwise, program could use a copy of the capability – which it could modify Capability를 지키기 위한 3개의 mechanism이 사용되는 데 tag와 protect memory, cryptography입니다. Tag의 경우 두가 지 state를 가지는데 set과 unset이 있고 hardware word와 관련이 있습니다. Set state의 경우 보통의 프로세서들이 어떤 hardware word를 읽을 수 는 있지만 수정은 할 수 없고 unset state는 해당 word를 읽고 수정할 수 있습니다. 두 번째 방법은 protect memory인데 주로 paging/segmentation protection을 들 수 있습니다. 이 방식은 테그와 비슷하지만 수정할 수는 없고 읽기만 가능하도록 구현되어 있습니다. CAP 시스템이 이를 사용합니다. 프로그램은 반드시 포인터를 통해 해당 word를 사용할 수 있고 수정해야 할 필요가 있을 경우 복제본을 통해 수정된 내용을 사용할 수 있습니다.

19 Implementation Cryptography
Associate with each capability a cryptographic checksum enciphered using a key known to OS When process presents capability, OS validates checksum Example: Amoeba, a distributed capability-based system Capability is (name, creating_server, rights, check_field) and is given to owner of object Check_field is 48-bit random number; also stored in table corresponding to creating_server To validate, system compares check_field of capability with that stored in creating_server table Vulnerable if capability disclosed to another process 세번째로 암호화의 경우 실제 위의 두가지 방법은 capability의 변질을 막기 위한 방법이라고 할 수 있습니다. 이는 integrity를 확인하기 위한 방법이라고도 할 수 있는데 암호화를 통해 이를 해결할 수 있습니다. 각 capability는 그와 관련되어 checksum을 구하고 이를 OS가 알고 있는 key를 통해 암호화합니다. 그리고 이렇게 암호화된 checksum을 OS가 프로세서가 capability를 보이면 이를 비교하여 결과를 도출할 수 있습니다. 그 예로 Amoeba라는 시스템이 있는데 이는 분산 ~~~시스템이라고 할 수 있습니다. 1. Object의 이름, 만든 서버, 권한, check field 2. 3. 4. 다른 프로세서에게 capability가 노출되면 취약하다는 점이 존재합니다.

20 Copying and Amplifying
Allows temporary increase of privileges Example Suppose x is a counter Initially the capability for x contain the right to the count module only If Object is passed to the count module, the processor must now have more right Copy와 증폭에 대해 설명하겠습니다. 실제 Capability를 사용하는 시스템에서 이를 copy한 다는 것은 다른 사람에게 권한을 부여한 다는 것과 동일하다고 할 수 있습니다. 따라서 copy를 수행하는 것에 대해 copy flag를 두어 이를 통제하는데 앞서 말한 tag 구조처럼 set의 경우 복제를 할 수 없도록 하였습니다. 그리고 Amplifying은 privilege의 일시적인 확장을 의미하는 입니다.

21 Revocation Not that easy like we do in ACL
Scan all C-lists, remove relevant capabilities Too expensive! Alternative method : Indeirection mechanism Object table : Each object has a corresponding entry in a table Capability의 경우 ACL과 다르게 revoke하는 것이 쉽지 않습니다. 모든 C-list를 확인해서 관계가 있는 모든 capability를 삭제해야하기 때문에 그 비용이 많이 들기 때문입니다. 이를 해결하기 위해 대안으로 나온 것이 바로 indirection mechanism입니다. 이와 같은 방식은 2가지 이점이 있습니다. 하나는 capability가 삭제될 때 global object table에서 옳지 않은 부분을 찾아 다른 capability를 삭제할 수 있고 두번째는 단지 몇몇 capability만 삭제될 때 object가 가지는 다른 group이나 권한과 관련된 여러 entry 중에 해당 부분만 삭제하여 나머지를 사용할 수 있다는 것입니다.

22 Comparison with Access Control Lists
Both theoretically equivalent; consider 2 questions Given a subject, what objects can it access, and how? Given an object, what subjects can access it, and how? 지금까지 설명한 방식과 앞서 설명한 ACL의 차이점을 정리해서 설명하겠습니다. 두가지는 사실 access control matrix를 사용한다는 공통점이 있습니다. 하지만 다음 두 가지 물음에서 구분될 수 있습니다. 실제로 두가지 물음에 대해 두 방식 모두 대답이 될 수 있지만 첫번째는 C-List, 두번째는 ACL을 통해 더욱 쉽게 답을 찾을 수 있습니다.

23 Comparison with Access Control Lists
Suggested that the second question, which in the past has been of most interest, is the reason ACL-based systems more common than capability–based systems As first question becomes more important (in incident response, for example), this may change

24 Locks and Keys Cryptographic Implementation Type Checking Examples

25 Lock and Keys Associate information (lock) with object, information (key) with subject Latter controls what the subject can access and how Subject presents key; if it corresponds to any of the locks on the object, access granted This can be dynamic ACLs, C-Lists static and must be manually changed Locks and keys can change based on system constraints, other factors (not necessarily manual) Lock and key 기술은 ACL과 capability를 합쳐 놓은 것이라 할 수 있습니다. 일종의 열쇠와 자물쇠라고 생각할 수 있는데 object에는 lock을 걸고, subject가 key를 가지고 있어서 어떤 subject가 object에 access 하고자 할 때 key와 lock을 비교하여 일치하는지 여기서 일치한다는 말은 맞는 열쇠인지 확인하여 접근 허용여부를 결정하겠다는 것입니다. 후자는 subject가 무엇에 어떻게 access 하는지를 제어합니다. 키를 통해 원하는 object에 부합하는지 확인하여 access를 승인하기 때문입니다. 이러한 방식의 이점은 다른 방식보다 dynamic한 환경을 가질 수 있다는 것입니다. 실제 ACL이나 C-list의 경우 manual하게 변경해야 하지만 이는 시스템 제약이나 manual이 아닌 다른 요소에 의해 결정된다고 할 수 있습니다.

26 Cryptographic Implementation
Object is enciphered with a cryptographic key(lock); Subject has a Deciphering key(key) Encipher object o; store Ek(o) Use subject’s key k’ to compute D’k(Ek(o)) Any of n can access o : O’=(E1(o),…,En(o)) Requires consent of all n to access o : O’=(E1(E2(…(En(o))…)) Example IBM 370 system : access key, storage key, fetch bit 그리고 이러한 방식을 사용하기 위해 Gifford라는 사람이 제안한 Lock과 Key는 다음과 같습니다. 각 여러명의 subject가 동시에 o를 원한다면 각 object들은 각각에 부합하는 키를 가지고 있습니다. Or 연산과 같이 해당 object를 볼 수 있고, 모든 사람의 동의가 필요한 경우 다음과 같이 표현할 수 있습니다. Fetch bit이 cleared 즉 unset 되어 있으면 read만을 허용하고 fetch bit이 set되어 있고 nonuser mode로 access key가 0이면 page에 모두 쓸 수 있게 합니다. Access key가 0이 아닌 경우 storage key와 access key가 맞는 page만을 write할 수 있게 제한하고 있습니다. 마지막으로 access key가 0이고 storage key와 맞는 것이 하나도 없을 경우 deny합니다.

27 Type Checking Lock is type, key is operation
Example: UNIX system call write can’t work on directory(type) but does work on file(type) Example: PDP-11 Example : Windows Type checking은 lock and key의 방법 중 하나로 기본적인 subject와 object의 타입에 따라 접근을 제한하는 것입니다. PDP-11 system과 같은 많은 프로그램들이 이를 사용하고 있는데 실행은 instruction만 가능하고 data엔 read와 write가 가능하도록 한 것입니다.

28 Examples Logical coprocessor Kernel or Lock: Sidewinder firewall :
Compiler produces « data » Trusted process must change this type to « executable » before program can be executed Sidewinder firewall : Subjects are assigned domain, objects are assigned type Example: ingress packets get one type, egress packets another All actions controlled by type, so ingress packets cannot masquerade as egress packets (and vice versa) [Sidewinder firewall] Firewall 안에서 발생한 packet과 밖에서 발생한 packet 두 가지를 구분하여 공격자가 packet을 내부에서 발생한 것 처럼 속이려고 하여도 type이 다르기 때문에 접근이 제한됩니다.

29 Ring-Based Access Control
Reading/Writing/Appending Executing

30 Ring-Based Access Control
Segment right Read(r) Write(w) Append(a) Execute(e) Gates are entry points to available to other procedures 63 … Higher privilege Ring-based access control model은 memory나 disk 모두 비슷한 컨셉의 segment를 가지고 있다는 전제하에 개발된 AC모델입니다. 0에는 kernel이 있고 r number가 클수록 작은 privilege를 가지고 있다. 또한 각 프로시져는 ring 안에서 수행된다고 하는데 이는 ring이 각 개별적인 segment를 나타내기 때문입니다. 그리고 세그먼트가 가질 수 있는 권한은 read, write, append, execute가 있습니다. 또한 여기서 gate라는 용어를 사용하는데 이는

31 Reading/Writing/Appending
Procedure executing in ring r Data segment with access bracket(a1,a2) Mandatory access rule r ≤ a1 : access permitted a1 ≤r ≤ a2 : r and e permitted; w and a access denied a2 < r : all access denied Ring r에서 실해되는 procedure가 data segment에 접근하고자 할 때 관계되어 있는 data segment를 access bracket이라 하고 다음과 같이 표현할 수 있습니다. 다음 3가지 경우로 컨트롤 할 수 있습니다.

32 Executing Procedure executing in ring r
Call procedure in segment with access bracket(a1,a2) and call bracket(a2,a3) Often written (a1,a2,a3) Mandatory access rule r<a1 : allow access; ring-crossing fault a1≤r ≤a2 : allow access; no ring-crossing fault a2<r ≤a3 : allow access if through valid gate a3<r deny all access

33 Working Set-Based Access control
기존의 어디서나 untrusted한 데이터 교환 등이 증가함에 따라 바이러스나 웜 또는 말웨어에 의한 공격이 증가하고 있습니다. 이러한 utrusted한 device에서 네트워크 파일 서버로의 접근을 막기 위한 기법 바로 이 Working set based access control 모델입니다. 키 아이디어는 사용자가 신뢰할 만한 장비에서 사용을 할 때 사용자의 work set을 관찰하고 untrusted 장비에서는 접근하지 못하게 하기 위한 방법이라고 할 수 있습니다. 이 모델을 간단히 설명하자면 사용자의 정보를 수집한 POLEX라는 module이 있고 이는 trusted server에서의 사용자의 행동양식을 관찰하고 그 내용을 수집합니다. Working set에서 저장한 내용을 바탕으로 POLEX를 실행할 지 POLEN을 실행할지 결정하게 됩니다. POLEN이 실행된 경우는 read에 대해서는 해당 폴리시에 따라 file server로 부터 승인을 받고 write의 경우 작업하는 횟수나 trusted device에서 권한을 준 경우 write를 하게 되는데 이렇게 수행한 작업이 얼마나 신뢰성이 있는지 확인하고 임시로 저장된 공간에서 가져오게된다.

34 Criticality aware access control