Difference between revisions of "Security notes / Glossary"
m (→Role-Based Access Control (model)) |
m (→Access control) |
||
| Line 79: | Line 79: | ||
===Access control=== | ===Access control=== | ||
| + | |||
====Least privilege (principle)==== | ====Least privilege (principle)==== | ||
| Line 110: | Line 111: | ||
See also: | See also: | ||
* https://en.wikipedia.org/wiki/Principle_of_least_privilege | * https://en.wikipedia.org/wiki/Principle_of_least_privilege | ||
| + | |||
| + | |||
| + | <!-- | ||
| + | ====It's about enforcements, but also not so much==== | ||
| + | |||
| + | A system has to be able to enforce its own rules, or will not be secure at all. You had one job, etc. | ||
| + | |||
| + | But for the ''most'' part, that's up to implementation (and whether you can implement that securely on top of whatever you're building it on top of, but that too is implementation). | ||
| + | |||
| + | |||
| + | Its models are not ''doing'' that enforcement, | ||
| + | as much as discussion where the rules to enforce come from, | ||
| + | who and what controls them, | ||
| + | and whether that suits your actual needs. | ||
| + | (including "is it so annoying that people are going to intentionally break that model, or demand that you do that for them") | ||
| + | |||
| + | |||
| + | --> | ||
| + | |||
| + | |||
====Discretionary Access Control (model)==== | ====Discretionary Access Control (model)==== | ||
| Line 123: | Line 144: | ||
Examples: | Examples: | ||
: permissions in most filesystems | : permissions in most filesystems | ||
| + | |||
| + | |||
====Mandatory Access Control (model)==== | ====Mandatory Access Control (model)==== | ||
| Line 150: | Line 173: | ||
--> | --> | ||
| − | |||
| − | Role- | + | ====Role-Based Access Control==== |
| + | Role-based access control (RBAC) is focused on roles and role hierarchy, subjects and sessions. | ||
| − | It's a moderately detailed abstraction, | + | It's a moderately detailed abstraction, considered a thing of its own, |
| − | considered a thing of its own, | + | and a common reference for this sort of thing because these concepts cover a lot of typical needs of larger organisations |
| − | and | + | |
| + | |||
| + | This makes it (possibly mainly the role part) a potential piece of of DAC, MAC and others. | ||
| + | |||
| + | |||
| + | https://en.wikipedia.org/wiki/Role-based_access_control | ||
| + | |||
| + | |||
| + | |||
| + | ====Attribute-based access control==== | ||
<!-- | <!-- | ||
| − | + | Attribute-based access control (ABAC), like RBAC is more of a potential puzzle piece in a system. | |
| − | + | ||
| + | Instead of strongly defined concepts, ABAC lets rules include more arbitrary attributes set on objects. | ||
| + | |||
| + | |||
| + | It can be more fine-grained -- but is also more easily out of your control. | ||
| − | |||
--> | --> | ||
| Line 172: | Line 205: | ||
| − | + | ||
| + | |||
====Related notes==== | ====Related notes==== | ||
Revision as of 18:44, 6 January 2022
| Security related stuff.
Practical
|
Attacks
Access control
Least privilege (principle)
The principle of least privilege means each actor in a system should be able to access no more than it needs.
For example, you can say
- your web server should be denied to real all of the filesystem, except its own documents
- your backup program should
- be able to read most everything, but...
- not be able to run anything (beyond its own components)
- not be able to write anything except to the backup disk and its own logs
This is part of why functional accounts are often created for each such part:
It's easier to handle this in broad terms even in simpler DAC setups, with just filesystem permissions.
When you want to crack down on this more thoroughly and more visibly, look at things like SELinux (because it adds MAC).
Note that the isolation in VMs and OS containers, are implicitly least-privilege as well: no connection to the outside unless permitted.
See also:
Discretionary Access Control (model)
Discretionary access control (DAC) means access to an object is at the discretion of the object's owner.
...more precisely, the identity of subjects.
Usually that's owner-based, though e.g. capability systems often allow transfer to other parts.
Mainly contrasted with MAC
Examples:
- permissions in most filesystems
Mandatory Access Control (model)
Mandatory access control (MAC) means that the system that decides access between objects, instead of (or on top of) the object owners.
Often means labeling objects with particular categories, and having rules based on these categories.
Such (often-broad) labeling is often done for practical reasons: it often makes the rules simpler, which makes it more clear they express what you intended.
MAC usually means design up front,
and reconsidering that full design on each change.
This is also why it often assists DAC, because
- while MAC is good at partitioning off parts of a system in broad terms (e.g. web server may only read under /var/www regardless of permissions),
- MAC it is less flexible at anything you can't describe fully at the design stage (like people sharing specific files securely).
- while you can sort of implement DAC with MAC, this is often so messy
- to the point that it may be harder to verify as being correct
Role-Based Access Control
Role-based access control (RBAC) is focused on roles and role hierarchy, subjects and sessions.
It's a moderately detailed abstraction, considered a thing of its own, and a common reference for this sort of thing because these concepts cover a lot of typical needs of larger organisations
This makes it (possibly mainly the role part) a potential piece of of DAC, MAC and others.
https://en.wikipedia.org/wiki/Role-based_access_control
Attribute-based access control
Related notes
If you squint, there is sometimes very little difference between a category that a MAC system works on and a group that a DAC works on.
That is, very similar to users
The difference lies largely in who may change them - the admin, or the relevant user.
This is also roughly why there is value in mixing them. E.g. stricly separate web server, database, and other in terms of many resources. And have users as a third general pile, they can figure out among themselves and mostly just care about filesystem DAC anyway.
Hacking terminology
Passive recon
Attack vector
Attack surface
Attack factor
Attack tree
Red Team
Unsorted
Forward secrecy
Basically, it refers to protocols that, instead of using one secret key for everything, negotiate unique keys for each session based on a secret key.
This because that session key might be found out if someone invests significant time in finding it for a session they recorded from the network.
Even if they actually find that, it does not reveal the secret, or any other session keys,
and the term 'forward secrecy' basically points out that the secret key does not lose value after such an event.
https://en.wikipedia.org/wiki/Forward_secrecy
