0

Take the following examples:

  1. When I run sshd, it can in theory grant access to anything that the process itself has access to, regardless of provided credentials. For example, I could in theory modify a single if statement in the sshd source to grant access to my home directory to anyone.

  2. On the other hand, if I encrypt my home directory and it can only be decrypted with my login password, sshd (and a local root session, for that matter) could only access that information with either my password or some extreme coincidence of poor and malicious programming.

In the first case, my home directory is compromised if a single predicate misbehaves in sshd. In the second case, a compromise, accidental or otherwise, is extremely unlikely unless my password is compromised or the encryption algorithm is flawed.

We could also include analogous physical scenarios, and (in some sense) "security through obscurity", e.g., ssh couldn't connect to my machine without knowing its IP address.

Does this distinction occur somewhere in the discourse of access control? For example, if I wanted to refer to a system where an unreliable agent can easily compromise access, vs. one where that is extremely unlikely. (It seems like this is a superset of the DAC vs. MAC distinction.)

Kevin P. Barry
  • 103
  • 2
  • 1
    I think you're talking about *defense in depth*, ie. the layer of encryption is in addition to the requirement to pass a valid login challenge. @david-stratton *2013* [provides a decent overview of the concept](https://security.stackexchange.com/a/29270/228961) – brynk Nov 15 '20 at 01:55
  • @brynk Thanks! That sounds related, but I'm wondering more about the properties of a single layer of defense. Specifically, the vast majority of programmers wouldn't be comfortable trying to implement something like `sshd` because code soundness is the only thing stopping a compromise. The nature of it having unlimited access in the absence of credentials is what creates the risk for the programmer. For example, even if they delegate authn to PAM, they could still ignore the response. – Kevin P. Barry Nov 15 '20 at 03:05
  • In contrast, if you think a decryption program has bugs in it, it's still very unlikely that it's going to decrypt your data for the wrong person if the encryption itself is sound. – Kevin P. Barry Nov 15 '20 at 03:28
  • Perhaps what I'm looking for is a categorization based on how easy it would be for a system to *fail open*. For example, a firewall can fail open or fail closed, but it's unlikely that decryption will fail open. – Kevin P. Barry Nov 15 '20 at 07:23

1 Answers1

2

Why are you classifying a vulnerability leading to unauthorised access in sshd differently from that in encryption? In comments. you are differentiating based on "likelihood", but if you are talking conceptually, then they are equivalent and they are universally applicable in any discussion of access control. And since the concept is universal, it makes no sense to somehow discuss them separately.

What you are actually talking about is the process of risk assessment. That process occurs on a separate layer than simply discussing "access control". Risk assessments require context, which is where you then bring up likelihoods and impacts of the specific elements and threats involved. Risk assessments need to be done with every layer of control, including access control.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • So in a risk assessment there's no standard way to account for a single component that is very likely to fail open if it has a defect? Or do you just assume that something will always fail open if it's defective? – Kevin P. Barry Nov 15 '20 at 18:54
  • 1
    I'm saying that in a discourse of access control, a risk assessment is a distinct step, and that step can be made no matter what you are talking about. Of course there is a standard way to assess a single component's likelihood of failure. But that assessment is not unique to access control. – schroeder Nov 15 '20 at 19:35