Security notes / Glossary: Difference between revisions

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.

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.

DAC is mainly contrasted with MAC

Examples:

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

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

Unsorted

Forward and backward secrecy

Man in the middle

Two generals problem

The bitter ex test

Phishing

Worm, virus, trojan, etc.

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

End to end encryption

Zero knowledge

@@ Line 525: / Line 525: @@
 '''The two generals problem''' helps illustrate what you can and can't do over unreliable channels - which also has implications for security.
-Basicaly, two bits of army need to communicate, but their messenger may be intercepted.
-Is it possible for those two generals to coordinate, even if the messenger might get intercepted?
+Basically, two bits of army need to communicate, but their messenger may be intercepted.
+Assume that we can send precise messages.
+Assume that the messages cannot be imitated (we have something that serves as authentication).
-This turns out this is unsolvable, and you can even prove that - though it takes more than a few thoughts to do so.
+Whether it can be made unreadable (effective encryption) is relatively secondary.
-We assume that is possible to send precise messages, and can make them them impossible to imitate - those are not the issue at hand.
+Is it possible for those two generals to coordinate usefully, even if the messenger might get intercepted?
+Even without reading the contents (if you ''do'' have encryption), just making it ''not arrive'' can have serious implications
+This turns out this is unsolvable, and you can even prove that - though it takes more than a little work to do so.
+Intuitively, the issue is that that the last was intercepted leads to various issues,
+''some'' of which you can absolutely solve, but others that you cannot.
-Intuitively, the issue is that that the last was intercepted leads to various issues, ''some'' of which you can solve,
-but others that you cannot.
 In particular, it means you may always be one step behind agreement or acknowledgment, even if most of your messages are acknowledgment.
 You can force the issue ''in abstraction'' by baking in a "I agree to never change my mind",
-but that's not actually coordination anymore - particularly in the example's practice where the intercepting army may find out about the actual message,
+but then it's no useful coordination anymore - particularly in the example's practice where the intercepting army may find out about the actual message,
 but even without that being an issue (e.g. using encryption).