Скачать презентацию Access Control and Protection CS 155 Lecture 2 Скачать презентацию Access Control and Protection CS 155 Lecture 2

e41d1fcb5be28b3698ec11163ae470fe.ppt

  • Количество слайдов: 54

Access Control and Protection CS 155 Lecture 2 Tal Garfinkel Access Control and Protection CS 155 Lecture 2 Tal Garfinkel

Todays Agenda • Lots of new language/models for talking about security systems – Capabilities, Todays Agenda • Lots of new language/models for talking about security systems – Capabilities, ACL’s, DTE – How do we talk about existing systems – What to consider in a new design? • Discussion of how some existing systems work e. g. unix access controls

Overview • • • Access control: What and Why Abstract Models of Access Control Overview • • • Access control: What and Why Abstract Models of Access Control The Unix Access Control Model Capabilities Beyond the Unix Model Multilevel Security

What goes into system security? 1. Authentication (password/crypto/etc. ) 1. 2. Authorization (Acess control) What goes into system security? 1. Authentication (password/crypto/etc. ) 1. 2. Authorization (Acess control) 1. 2. 3. Who are you? this is a big part of CS 255 What are you allowed to do. Focus is policy Enforcement Mechanism - How its policy implemented/enforced Today we are mostly interested in #2, will touch on #3 Note: split between policy and mechanism sometimes a false dichotomy.

Night Club Example • Authentication – ID Check • Access Control – Over 18 Night Club Example • Authentication – ID Check • Access Control – Over 18 - allowed in – Over 21 - allowed to drink – On VIP List - allowed to access VIP area • Enforcement Mechanism – Walls, Doors, Locks, Bouncers

Night Club Example: More Interesting Phenomena • Tickets – Name or anonymous? – Date Night Club Example: More Interesting Phenomena • Tickets – Name or anonymous? – Date • What if you want to leave and come back – Hand stamp or bracelet

Why this Tangent? • We can find logical models to study these systems? • Why this Tangent? • We can find logical models to study these systems? • We can use these models to design new systems? • Security systems are everywhere, looking at the real world key to building your intuition.

What do we use this for? • Express information access policies. – Who can What do we use this for? • Express information access policies. – Who can access my files, who can’t, how. • Sandboxing: Minimize damage inflicted by malicous program. • Privilege Seperation: Allow programs to be written to minimize damage in case of failure. – Think about compartments in a ship Defense-in-Depth - programmers make mistakes, protection systems fail, redundancy always a good thing!!

Basic Design Space • All security architectures are Isolation + Controlled Sharing • Just Basic Design Space • All security architectures are Isolation + Controlled Sharing • Just Isolation – Unplug the network cable! (airgap provides almost perfect isolation). – Segment your network physically • Put red tape on one set of wires and machines, black tape on another, blue on another. • Make sure colors always match! – Military exploits this approach to separate classified, secret, topsecret networks. • Most of us need to share stuff…what do we want from sharing?

Challenge of Controlled Sharing • All of Saltzer and Schroder’s principles are vital, these Challenge of Controlled Sharing • All of Saltzer and Schroder’s principles are vital, these two are hard. 1. Principle of Least privilege 1. Make controls granular enough and apply them to enforce them to minimize harm. 2. Psychological acceptability 1. Get as close to the users mental model (be it the programmer, user or admin) as possible. Reconciling these two is a fundamental challenge.

Operating Systems: Our focus today • Most heavily studied area for access control • Operating Systems: Our focus today • Most heavily studied area for access control • First computers where single user/no network • Timesharing systems introduced need for access control – studied heavily in the 70’s and 80’s. • Still an open research area, why? – First 20 years: restrict what a user can do with data, focus on military problems, thought problem was malicous users – Last 10: Malicous applications the primary problem. • Another answer: Right Access control policy dictated by Usage models, Threat Model, Applications -- we still have lots to learn about how programs are built, how people use them.

Access Control vs. IDS and AV • Soundness (can I make a definite allow/deny Access Control vs. IDS and AV • Soundness (can I make a definite allow/deny decision) – Difference between access control and intrusion detection – An IDS makes a probablistic statement i. e. this action is probably bad allows catching a broader range of behaviors, at the cost of enforcement. – An IDS that is 100% accurate should be doing enforcement, it is then an IPS (access control system) • Completeness (do I catch every bad action) – Access control vs. AV – Access control systems should (in theory enforce some property) -- e. g enforce these rules on information flow. – AV systems often rely more on un-sound blacklist approach, hard to make strict statements about what your getting • In the real world, distinctions often unclear – Your AV product may do some access control

Abstract Models of Access Control Abstract Models of Access Control

Subjects and Objects • Subjects – can be processes, modules, roles • Objects – Subjects and Objects • Subjects – can be processes, modules, roles • Objects – can be files, processes, etc. • Authentication often used to bootstrap subjects, but not necessary. – e. g. process assumes identity of one subject, then another.

Elementary Forms • Authentication = Authorization – e. g. safes • Whitelists/Blacklists (Single object, Elementary Forms • Authentication = Authorization – e. g. safes • Whitelists/Blacklists (Single object, multiple Subjects) – Examples: Spam prevention – Blacklists: • Default on (fail open) • Hard to reason about who can access system – Whitelists: • Default off (fail closed) • Have to deal with adding whitelist entries • Challenges • Hard to manage if rapidly changing set of principles • Both can grow quite large

Access Control Matrix • Instantaneous protection state of a system • Dynamically Changing! • Access Control Matrix • Instantaneous protection state of a system • Dynamically Changing! • How can we extend this model? Objects A alice 0 subjects bob 1 charlie 0 dave 1 B 0 1 C 1 0 D 0 1

Adding Access Rights • Access Rights – e. g. Simple: Read, Write – e. Adding Access Rights • Access Rights – e. g. Simple: Read, Write – e. g. Complex: execute, change ownership Objects A alice r subjects bob r charlie dave B C D r/w r w - r/w w

Grouping • Subjects – Groups e. g. staff = {alice, dave}, students = {bob, Grouping • Subjects – Groups e. g. staff = {alice, dave}, students = {bob, charlie} • Objects – Types e. g. system_file = {A, B}, user_file = {C, D} • Can have compound names – e. g. in AFS talg: friends, system: backup

ACL’s • What if I break my matrix down by columns? – Each object ACL’s • What if I break my matrix down by columns? – Each object has a set of tuples – A {, } • Properties – Good for many applications (file systems) – Can grow quite large

Capabilities • What if I break my matrix down by rows – Alice {<A, Capabilities • What if I break my matrix down by rows – Alice {, , } • Properties – Natural model for delegation (rights coupled to object) • Each tuple can be viewed as a handle to an object

Protection Domains • Users don’t exist – Machines, processes, modules, do • Protection domain Protection Domains • Users don’t exist – Machines, processes, modules, do • Protection domain is an abstract object that can have – – A namespace (e. g. view of the file system) A userid or group ID A set of objects it holds (capability list) A set of rights it holds (permissions) • How does protection get enforced? – Language type systems, hardware MMU (Processes, virtual machines), compilers (SFI) – Not our primary interest today

The Reference Monitor • An abstract model of protection – – • In practice The Reference Monitor • An abstract model of protection – – • In practice should offer: – – – • Sometimes quite close to implementation e. g. SELinux (Flask Architecture) Complete mediation Be Tamper proof Be small enough to understand (verify) Important Idea: Computer systems are BIG and Complex, Security relavent part often SMALL, extract that part out that deals with security so that we can understand/verify it.

Unix Access Control Basics, limitations, extensions Unix Access Control Basics, limitations, extensions

Unix Resource • Files • Includes devices, IPC (domain sockets, named pipes, mmap shared Unix Resource • Files • Includes devices, IPC (domain sockets, named pipes, mmap shared memory) • Network • TCP/UDP port address space • Other – Sys V IPC has its own name space – ability to load kernel modules

Unix Identities • Each process has set of identities used to make access control Unix Identities • Each process has set of identities used to make access control decisions. – Conceptually uid/euid, gid/egid most important – In practice, a bunch of other details, see reading. • euid used for access control decisions – Allows process to drop and resume privilege temporarily • Changing uid/euid allows dropping privilege permanently.

File system access control user group other • “-rwxrwxrwx • “-rw------- talg vimrc” • File system access control user group other • “-rwxrwxrwx • “-rw------- talg vimrc” • “-r-sr-xr-x root wheel chpass” • New files created according to “umask” • setuid bit for executables - changes uid to uid of file owner on exec() of file. • Execute on directory implies access to directory.

What can you do with identities • Lots of hard coded rules • Highest What can you do with identities • Lots of hard coded rules • Highest privilege uid is root (uid = 0), has most privilege, – Access privileged ports, override file permissions, load kernel modules, etc. – Once you have root, you own the system – this is a source of many problems. • Process with a given euid can send signals to other processes with that uid, ptrace() those processes, etc. – Basically no protection between processes with same uid. • Good news – Works decently well on multi-user system where programs are not malicous -- shortcomings can be fixed with file system ACL’s • Bad News – Very difficult/sometimes impossible to contain damage of malicous root process – Lots of stuff needs root – Users can’t protect themselves from bad apps, i. e. apps totally trusted!!

Dropping privilege • Only available to root • To prevent programmer errors – Assume Dropping privilege • Only available to root • To prevent programmer errors – Assume role of less privileged user for most operations (seteuid) • Let OS do its job – – Only keep privilege long enough to do what you need. Temporary, program can resume root privilege at will Essential for some things in unix (e. g. race free file open) NEVER try to impersonate another user as root! • You will fail • To prevent malicous code from inflicting damage – Drop privilege permanantly (often accompanied by fork()). – Works well if there is a before-time (with privilege)/aftertime(without privilege) model. e. g. daemons that need root to listen to privileged port.

 • Seperating Time of Check and Time of Use - A Really Bad • Seperating Time of Check and Time of Use - A Really Bad Thing Example: access() system call. int access(const char *path, int mode); #From the man page: #Access() is a potential security hole and should never be used. • Problem: as soon as you get a result from access(), its invalid. Permissions could have changed. – Checking Permission/obtaining resource must be atomic! • Solution: Never use access(), instead look up programming guidelines for your OS. Hint: Never make up your own solution!

Capabilities They are cool Capabilities They are cool

Confused Deputy Problem 1. 2. 3. 4. Pay-to-play compiler service (its an old problem) Confused Deputy Problem 1. 2. 3. 4. Pay-to-play compiler service (its an old problem) Compiler service takes file and compiles it for user User hands compiler path for compilers own billing file Compiler overwrites billing file Compiler was a confused deputy - acting on behalf of user. 1. Solutions: 1. Drop privilege to that of user to open file (more error prone, common source of bugs) 2. Have user pass capability to compiler (less error prone). 3. Capability advocates love to point this out as reason to use capabilities.

File descriptor passing: the poor mans capability system • File descriptors are capabilities • File descriptor passing: the poor mans capability system • File descriptors are capabilities • Ability to delegate files by passing descriptors over a unix domain socket (sendmsg(), recvmsg()) • Supports privilege seperation • – One process runs as root, opens a unix domain socketpair. – Forks() another process, drops privilege – More privilege process can pass descriptors to less privilege process, also do other stuff e. g. manage crypto keys. – Can apply this paradigm ad naseum i. e. multiple unprivileged processes. Trade-offs – Positive: Great way to make more robust software – Negative: sometimes very hard to do after the fact (don’t believe the hype), requires pretty clueful programmers up front.

Capabilities have lots of nice properties • Natural model for delegation – Just pass Capabilities have lots of nice properties • Natural model for delegation – Just pass handle to object • No ambient privilege – Access control explicit not implicit • Separate access checking from use – E. g. fd = open() vs. read(fd), write(fd) – Useful design pattern for ammoritizing the cost of permission checks • Powerful extensibility in languages that support capabilities natively – Wrap one object in another object.

Still More… • Cryptographic Capabilities – Nonce as index into table (stateful) – {<permissions>, Still More… • Cryptographic Capabilities – Nonce as index into table (stateful) – {, objectid, MAC(msg)} (stateless) – No OS support need, good for distributed systems • Limitations of capabilities – No easy means of revocation – Can’t easily control delegation in a pure model (mostly a red herring) – Doesn’t always suit your problem

Some Real World Access Control Mechanisms Or, overcoming the shortcomings of the original Unix Some Real World Access Control Mechanisms Or, overcoming the shortcomings of the original Unix model.

Dangers of bad access control model • Too much privilege! – Original Unix architecture Dangers of bad access control model • Too much privilege! – Original Unix architecture suffers severly – Windows world even worse – Once ISV’s (developers) expect this, very hard to go back! • Wrong granularity – To coarse grain => too much privilege – To fine grain => too many knobs, no one knows how to use it • (SELinux struggles with this, its gotten better, but still not for the faint of heart) – Compromise • Protection Profiles, Roles, etc. - use fine grain permissions to build up common case profiles.

File system ACL’s • Basic Problem – I want to do a project with File system ACL’s • Basic Problem – I want to do a project with a new group, how do I share files with only them without involving my sysadmin? • Ghetto style – – Create a directory accessible but not readable by everyone Make directory (or files) in that directory with secret name Hand out name as a capability Gross and many limitations… • ACL’s a better soluation – User created groups, user setable list of groups/users on files/directories • Almost everywhere now – AFS, NTFS, NFSv 4, Free. BSD, Solaris, ZFS, etc.

Chroot() • Basic idea: Allow process to change file system root: e. g. chroot(“/home/apache/base”); Chroot() • Basic idea: Allow process to change file system root: e. g. chroot(“/home/apache/base”); / • Variety of sharp edges due to power of root user, ptrace(), etc. • BSD Jail tries to fix this. • Fundamental problem, limited controlled sharing. • Still, a useful primitive • Richer primitive in plan 9, a research OS. etc home bin apache base etc bin

Posix “Capabilities” • Paritioning power of root – CAP_DAC_OVERRIDE: ignore normal file permissions – Posix “Capabilities” • Paritioning power of root – CAP_DAC_OVERRIDE: ignore normal file permissions – CAP_CHOWN: allow arbitrary chown – CAP_SYS_NET_BIND_SERVICE: allow bind of TCP/UPD sockets below port 1024 – CAP_NET_RAW: allow raw socket access (can create arbitrary ethernet frames) • Improvement on setuid – Doesn’t help with files – Fixed granularity

Sandboxing Systems • Examples: App. Armor (Su. Se), Systrace, Janus Sandboxing Systems • Examples: App. Armor (Su. Se), Systrace, Janus

SELinux • Adding MAC to Linux • Flexible policy architecture – DTE, RBAC, MLS SELinux • Adding MAC to Linux • Flexible policy architecture – DTE, RBAC, MLS • Default uses combination of RBAC and DTE • Checks applied if existing unix model succeeds e. g. if access fails, additional checks not invoked • Most folks never use MLS

Domain and Type Enforcement • • • Generalization of Access Control Matrix Processes have Domain and Type Enforcement • • • Generalization of Access Control Matrix Processes have a domain Objects (generally files) have a type. – Stored in extended file attribute – Type set at system configuration time. Example: assign -u /home user_t assign -u /var spool_t • • • Entry point to domain is generally a binary e. g. (exec /usr/bin/lpd => domain lpd_t) App can request a domain transition to drop privilege Nice compared to path base model in that more robust to file rename(), can be less prone to problems due to symlinks, etc.

RBAC • Yet another generalization of our access control matrix – Add yet another RBAC • Yet another generalization of our access control matrix – Add yet another label to processes – Instead of uid, access control decisions based on role – e. g. Bob acting as backup manager vs. bob acting as printing manager.

A few words on Policy Languages • Policy language at heart of rationale for A few words on Policy Languages • Policy language at heart of rationale for access control – Look at policy spec instead of entire program/system – Clarity/simplicity key • Even ACLs have a policy language • Different requirements than programming language – Often non-expert users – Must be right the first time! • Tension between flexibility/expressiveness and simplicity – Compare ACL’s, to App. Armor to SELinux

Sample SELinux TE Policy for FTPD • • ################# # # Rules for the Sample SELinux TE Policy for FTPD • • ################# # # Rules for the ftpd_t domain # type ftp_port_t, port_type; type ftp_data_port_t, port_type; daemon_domain(ftpd, `, auth_chkpwd') type etc_ftpd_t, file_type, sysadmfile; • • • can_network(ftpd_t) can_ypbind(ftpd_t) allow ftpd_t self: unix_dgram_socket create_socket_perms; allow ftpd_t self: unix_stream_socket create_socket_perms; • tc • • allow ftpd_t self: process {ge ap setcap}; allow ftpd_t self: fifo_file rw_file_perms; • • • allow ftpd_t bin_t: dir search; can_exec(ftpd_t, bin_t) allow ftpd_t { sysctl_t sysctl_kernel_t }: dir search; allow ftpd_t sysctl_kernel_t: file { getattr read }; allow ftpd_t urandom_device_t: chr_file { getattr read }; • • ifdef(`crond. te', ` system_crond_entry(ftpd_exec_t, ftpd_t) can_exec(ftpd_t, { sbin_t shell_exec_t }) ') • allow ftpd_t ftp_data_port_t: tcp_socket name_bind; • ifdef(`ftpd_daemon', ` • define(`ftpd_is_daemon', `') • ') dnl end ftpd_daemon • ifdef(`ftpd_is_daemon', ` • rw_dir_create_file(ftpd_t, var_lock_t) • allow ftpd_t ftp_port_t: tcp_socket name_bind; • allow ftpd_t self: unix_dgram_socket { sendto }; • can_tcp_connect(userdomain, ftpd_t) • ', ` • ifdef(`inetd. te', ` • domain_auto_trans(inetd_t, ftpd_exec_t, ftpd_t) • ifdef(`tcpd. te', `domain_auto_trans(tcpd_t, ftpd_exec_t, ftpd_t)') • # Use sockets inherited from inetd. • allow ftpd_t inetd_t: fd use; • allow ftpd_t inetd_t: tcp_socket rw_stream_socket_perms; • # Send SIGCHLD to inetd on death. • allow ftpd_t inetd_t: process sigchld; • ') dnl end inetd. te • ')dnl end (else) ftp_is_daemon • ifdef(`ftp_shm', ` • allow ftpd_t tmpfs_t: file { read write }; • allow ftpd_t { tmpfs_t initrc_t }: shm { read write unix_read unix_write associate }; • ') • # Use capabilities. • allow ftpd_t: capability { net_bind_service setuid setgid fowner fsetid chown sys_resource sys_chroot }; • # Append to /var/log/wtmp. • allow ftpd_t wtmp_t: file { getattr append }; • …

Whole System Containers • Solaris Zones, OS Level Virtual Machines • Given application completely Whole System Containers • Solaris Zones, OS Level Virtual Machines • Given application completely private view of OS • Great for isolation, no sharing model. • Same camp as virtual machines – the right tool for some jobs – large topic in its own right

Multilevel Security Multilevel Security

Classical military model • Vertical classification levels – Confidential < Secret < Top Secret Classical military model • Vertical classification levels – Confidential < Secret < Top Secret • Horizontal compartments – Nuclear, SIGINT, Biowar, etc. • User has a level, can’t read above that level (violates secrecy), can’t write below that level (leaks data). • Process can begin with – Upperbound (read), lowerbound (write) – Lower bound raised every time information read from above.

Bell-Lapadula • No read up, no write down <Top Secret, {Nuclear, Biowar}> <Top Secret, Bell-Lapadula • No read up, no write down

MLS in the world • Classification level added by tagging files – Just like MLS in the world • Classification level added by tagging files – Just like DTE • Everything tends to flow up – Ends up being very cumbersome in practice • Declassification – Don’t know how to automate this, human in the loop – Becomes a bottle neck in critical situations (e. g. 9/11) • Almost no one uses this in practice • Tagging data with sensitive labels a cool idea, maybe could be used to help protect your personal data from malware

Biba-Integrity Model • Cool Observation: Integrity the opposite of secrecy -- low integrity data Biba-Integrity Model • Cool Observation: Integrity the opposite of secrecy -- low integrity data flowing upwards leads to system compromise. • Biba Rules – No read down – No write up • Again, tends to be kind of unwieldly, can make sense for some systems.

The Confinement Problem • In real life, really hard to prevent to colaborating processes The Confinement Problem • In real life, really hard to prevent to colaborating processes from communicating (say in order to write down). – Often due to timing channels • Communication path called a “covert channel” • Real world systems that care (very few) try to limit bandwidth. • Lampsons “Notes on the confinement Problem” a must read.

Closing thoughts Closing thoughts

Most of you will go off to companies to write code • Many attacks Most of you will go off to companies to write code • Many attacks seen in the wild could have been rendered moot if software used access controls properly. • Learn the access control system of your language runtime and OS – Learn their strengths and pitfalls. • Build systems according to saltzer and schroders principles. – Be conservative in your design, assume things will fail, attempt to minize harm. • Building things right requires a bit more effort. • Fixing things later requires far more – sometimes impossible or impractical.