Security notes / Glossary

Security related stuff. Linux - PAM notes · SELinux Securing services Public key encryption; SSL and TLS SSH: tunnels, X forwarding · keypair logins · SSH jails · loose notes · agent Apache config and .htaccess - security A little more practical security for the everyday person not-so-formal notes Ingredients that might be useful to know - MFA / 2FA · One-Time Passwords; also, authenticators More techincal waffling Message signing notes · Hashing notes · Auth - Kinds of auth setup · identity and auth notes ·· OAuth notes · OpenID notes Kerberos notes · · SASL notes Encryption - Encryption notes · public key encryption notes · data-at-rest encryption · encrypted connections pre-boot authentication Unsorted - · Anonymization notes · website security notes · integrated security hardware · Glossary · unsorted

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:

• https://en.wikipedia.org/wiki/Principle_of_least_privilege

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 for practical reasons, though e.g. capability systems often allow transfer to other parts.

Examples:

permissions in most filesystems

DAC is mainly contrasted with MAC, where the system (not specific users on it) mediates access between objects.

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 a model applied on top, labeling all 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 each large change should probably re-evaluate all implications.

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 much less flexible at anything you can't describe fully at the design stage (e.g. people wanting to share files somewhat securely).

This is one reason MAC often assists DAC, using MAC to restrict the broad problems, and DAC for the more everyday things. (While you can sort of implement something much like DAC using MAC, this is often so messy that it may be harder to verify as being correct, and harder to administer in an everyday way)

Role-Based Access Control

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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

https://en.wikipedia.org/wiki/Role-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.

Unsorted

Terms and names

Confused deputy

Confused deputy attack - the confused deputy in question refers to an agent with authority that someone else doesn't have, who is fooled by some other party to misuse that authority (or otherwise act unlike they normally would)

http://en.wikipedia.org/wiki/Confused_Deputy

Evil maid

Evil maid attack - the idea that someone with physical access can alter a system for their later benefit.

Named for people easily leaving devices unattended in hotel rooms.

Man in the middle

A Man In The Middle attack happens when A and B think they're talking directly to each other, but are actually both talking to C.

For example, when A and B think they set up a secure connection to each other, and what's happening is that there are two connections: A to C and C to B, with C just repeating and listening in.

Alleviation: verification of identity via pre-shared secrets, trusted channel.

Such verification is often designed to be one-time because of cost/bother of doing it.

http://en.wikipedia.org/wiki/Man-in-the-middle_attack

Replay attack

A replay attack - a case where re-sending a sequence of previously captured data has value.

For example, if a series of bytes logged someone in, and sending exactly that thing again logs you in as them, then you don't even have to know what any of it means.

Alleviation: nonces and similar