Security notes / Glossary

From Helpful
Jump to: navigation, search
Security related stuff.


Theory / unsorted

how to do a login system badly
how to do encryption badly
encrypted connections
data-at-rest encryption


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


permissions in most filesystems

Mandatory Access Control (model)

Mandatory access control (MAC) means that the system that decides to allow access between objects, instead of the object owners (though some systems apply MAC on top of DAC)

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

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, or tell me)

Role-based access control (RBAC) is focused on roles and role hierarchy, subjects and sessions.

It's a moderately detailed abstraction, not yet a system in itself, but may be useful to architect into larger systems where you want to keep overview of what is allowed to happen and what is happening, particularly in larger organisations.

This makes it a potential piece of of DAC, MAC and others - probably replacing a simpler implementation of one of its parts (e.g. the role/account stuff).

Attribute-based access control

Related notes

If you squint, there is sometimes very little difference between a MAC category and a DAC group (whatever the preferred terms are).

That is, very similar to useand users - the remaining difference may lie largely in who may change the permissions - the admin, or the relevant user.

This is also roughly why there is value in combining MAC and DAC.

Hacking terminology

Passive recon

Attack vector

Attack surface, Attack factor

Attack tree

Red Team

Network stuff

DMZ network

DMZ host

Bastion host


Forward and backward secrecy

Man in the middle

Two generals problem

The bitter ex test


Worm, virus, trojan, etc.

Performative security, LARP security, pretend security, cargo cult security, security theater

End to end encryption

Zero knowledge