Difference between revisions of "Security notes / Glossary"

From Helpful
Jump to: navigation, search
m (Discretionary Access Control (model))
m (Mandatory Access Control (model))
Line 126: Line 126:
 
====Mandatory Access Control (model)====
 
====Mandatory Access Control (model)====
  
Mandatory access control (MAC) means the system, not the users, decides access between objects.
+
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 (usually with particular categories),
+
Often means labeling objects with particular categories, and having rules based on these 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.
  
...for practical reasons: it keeps the rules sane,
 
and in most cases sorting objects into categories is practical.
 
  
 +
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).
  
In various user this ''assists'' DAC,  
+
* while you can ''sort of'' implement DAC with MAC, this is often so messy
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), it is less flexible at anything you can't describe well up front (like people sharing specific files securely).
+
: to the point that it may be harder to verify as being correct
  
 
{{comment|(And while you can ''sort of'' implement DAC with MAC, it's not a very sane solution.)}}
 
  
 
<!--
 
<!--
 
Sometimes sort of imitates security agency / military style, and can be modeled off it if you want.
 
Sometimes sort of imitates security agency / military style, and can be modeled off it if you want.
 
-->
 
-->
 
  
 
====Role-Based Access Control (model)====
 
====Role-Based Access Control (model)====

Revision as of 14:12, 30 September 2021

Security related stuff.

Practical


Theory


Unsorted


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 (model)

Role-based access control (RBAC) does not refer directly to a way of implementing access control (like DAC and MAC), but to the the focus on roles and inheritance, that are often also present in DAC, MAC and others.

That said, it's a moderately detailed abstraction, so considered a thing of its own, and can be used to implement DAC and MAC (and others).


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.

...in what they mean to use - 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

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

Man in the middle

Two generals problem

The bitter ex test

Forward secrecy

Worm, virus, trojan, etc.