Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start 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.


Access Control and SELinux

No description

Sven Vermeulen

on 18 May 2011

Comments (0)

Please log in to add your comment.

Report abuse

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)
Domain example:
sysadm_t (for system administrator shell process) MLS Sensitivity Software-based This was Questions?
Full transcript