Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Do you really want to delete this prezi?
Neither you, nor the coeditors you shared it with will be able to recover it again.
Make your likes visible on Facebook?
You can change this under Settings & Account at any time.
Access Control and SELinux
Transcript of Access Control and SELinux
Control DAC MAC RBAC By Sven Vermeulen Discretion(ary Access Control) Grant or deny rights at the discretion of the user Make files publicly readable Read a "private" document and write it to a public location Change group ownership of file Limited set of supported privileges Is or Isn't "The" security component Works close with auditing Often matrix-based Governs system / resource access Security administrator defines the rules Security Policy Labeling Context Only security admin can change labels or delegate subset of labelling to users System Control Policy is forced Information Flow Read down Write up Integrity Compliance Read up Write down Activity & Process Flow Activity order Activity sequence = + Fine-Grained Authorizations with Multiple Resource Types Downsides Stand-alone Change-sensitive Instance-specific Expert-oriented Organizational SELinux Type Enforcement Role support Instantiation Security Levels MAC & DAC Consistent set of activities Low granularity targeted strict Medium granularity High granularity Usually for a small set of
application domains. over 80 "types" of resources called classes (file, dir, rawip_socket, netif, filesystem, kernel, ...) Hundreds of activities
(read, write, accept, open, receive,
lock, getattr, connectto, bind, polmatch,
shutdown, quotaon, dac_override, ...) A typical SELinux policy has
several thousand types
(domains & resources) Role-based Access MCS User-based Access SELinux users cannot be changed
Access can be "ubac" constrained
Users are granted roles user_u:role_r:domain_t
user_u:object_r:type_t Matrix for each permission
Subjects "act" on an object
Objects "undergo" activities No fine-grained access control methods user-based Network interfaces Ports System calls Capabilities Sockets Message queues Processes Knowledge of "business" Mandatory Access Control system for Linux
Generally Available since August 2003
Uses the Linux Security Modules
"Reference Policy" Resource example:
shadow_t (for /etc/shadow)
sysadm_t (for system administrator shell process) MLS Sensitivity Software-based This was Questions?