68 lines
3.0 KiB
Markdown
68 lines
3.0 KiB
Markdown
|
Lecture Topic: UNIX file access control
|
||
|
|
|
||
|
|
[Module Four PDF](https://lms.unb.ca/d2l/le/content/231513/viewContent/2614490/View)
|
||
|
|
|
||
|
|
# Unix file access control
|
||
|
|
|
||
|
|
Each Unix user is assigned a UUID, a user is also a member of a primary group, and possibly a number of other groups, each identified by a group ID
|
||
|
|
|
||
|
|
When a file is created, it is designed as owned by a particular user and marked with that users id, It also belongs to a specific group, which initially is is either its creators primary group or the group of its parents directory that has SETGID permission set
|
||
|
|
|
||
|
|
Associated with each file is a set of 12 protection bits
|
||
|
|
|
||
|
|
Table of Unix permissions goes here
|
||
|
|
## Superuser
|
||
|
|
|
||
|
|
One particular user ID is designated as "super user"
|
||
|
|
|
||
|
|
This user is exempt from the usual file access control constraints and has systemwide accesses.
|
||
|
|
|
||
|
|
Any program that is owned by, and SetUID to, the superuser potentially grants unrestricted access to the system. Great care must be taken when running or making programs which run as the superuser
|
||
|
|
|
||
|
|
## Access Control Lists in Unix
|
||
|
|
|
||
|
|
Many modern unix and unix based OS, support access control lists, including FreeBSD, OpenBSD and Solaris, often called the "extended access control list" while the traditional Unix system is called the "minimal access control list"
|
||
|
|
|
||
|
|
## Mandatory access control
|
||
|
|
|
||
|
|
In this nondiscretionary model, people are granted access based on information clearance.
|
||
|
|
|
||
|
|
A central authority regulates access rights based on different security levels
|
||
|
|
|
||
|
|
Policies are set by the administrator, the users cannot able to interact with permissions.
|
||
|
|
|
||
|
|
This model is common in military or government.
|
||
|
|
|
||
|
|
MAC puts strict controls on users and information being accessed
|
||
|
|
|
||
|
|
## Role-based access control
|
||
|
|
|
||
|
|
In RBAC, permissions are based on roles that users assume, rather than identity.
|
||
|
|
|
||
|
|
This is typically a job function within an organization.
|
||
|
|
|
||
|
|
Users are often given roles either statically or dynamically according to their responsibilities.
|
||
|
|
|
||
|
|
The relationship of users to roles is many to many, as is the relationship to roles to resources or system objects
|
||
|
|
|
||
|
|
The set of users changes, and the assignment of roles can often be dynamic
|
||
|
|
|
||
|
|
The set of roles is often static, usually only adding or deleting occasionally
|
||
|
|
|
||
|
|
Each role will often have access rights to one or more given resources. The set of resources that a role can access often does not change frequently as well.
|
||
|
|
|
||
|
|
Insert RBAC table example here
|
||
|
|
|
||
|
|
RBAC reference models
|
||
|
|
- RBAC0: This is the minimum for a RBAC system
|
||
|
|
- RBAC1: This is RBAC0 with the addition of role hierarchies, which enables role inheritance
|
||
|
|
- RBAC2: This is RBAC0 which adds constraints, which restrict the way in which componants of an RBAC system can be configured (ex, only x times a day)
|
||
|
|
- RBAC3: Is RBAC0, RBAC1 and RBAC2
|
||
|
|
|
||
|
|
## Attribute based access control
|
||
|
|
|
||
|
|
ABAC is a dynamic, context based policy that defines access based on policies granted by users. The system is used in identity and access management frameworks.
|
||
|
|
|
||
|
|
An ABAC model can define authorizations that express conditions on properties of both the resources and the subject
|
||
|
|
|
||
|
|
Long ass list in the slides
|