Monday, November 24, 2008

security...

No system is totally secure. Few systems are totally insecure. Most systems are between these two extremes. But what does "more secure" mean? We had an interesting discussion on the rsyslog mailing list on the use of root jails. I'd like to reproduce one of my posts here, not only because it is mine, but because it can guard us a bit towards the security goals for rsyslog.

Let me think of security as a probability of security breach. S_curr is the security of the reference system without a root jail. S_total is the security of a hypothetical system that is "totally secure" (knowing well that no such system exists). In other words, the probability S_total equals 0.

I think the common ground is that a root jail does not worsen security. Note that I do not say it improves security, only that it does not reduce a system's security. S_jail is the security of a system that is otherwise identical to the reference system, but with a root jail. Than S_jail <= s_curr, because we assume that the security of the system is not reduced.

I think it is also common ground that the probability of a security breach is reduced if the number of attack vectors is reduced, without any new attack vectors being added. [There is one generic "attack vector", the "thought of being secure and thus becoming careless" which always increases as risk is reduced - I will not include that vector in my thoughts]

We seem to be in agreement that a root jail is able to prevent some attacks from being successful. I can't enumerate them and it is probably useless to try to do so (because attackers invent new attacks each day), but there exist some attacks which can be prevented by a root jail. I do not try to weigh them by their importance.

For obvious reasons, there exist other attacks which are not affected by the root jail. Some of them have been mentions, like the class of in-memory based attacks, code injection and many more.

I tend to think that the set of attack vectors that can be prevented by a root jail is much smaller than the set of those which can not. I also tend to think that the later class contains the more serious attack vectors.

But even then, a root jail seems to remove a subset of the attack vectors that otherwise exist and so it reduces the probably of security breach. So it benefits security. We can only argue that it does not benefit security if we can show that in all cases we can think of (and those we can not), security is not improved. However, some cases have been show, where it improves, so it can not be that security is not improved in all cases. As such, a root jail improves security, or more precisely the probability of a security breach is

0 < S_jail < S_curr

We can identify the benefit we gain is the difference between the reference system's probability of security breach and the system with the jail. Be S_impr this improvement, than

S_impr = S_curr - S_jail

Now the root jail is just one potential security measure. We could now try to calculate S_impr for all kinds of security measures, for example a privilege drop. I find it hard to do the actual probability calculations, but I would guess that S_impr_privdop > S_impr_jail.

Based on the improvements, one may finally decide what to implement first (either at the code or admin level), all of this of course weighted with the importance of the numbers.

In any case, I think I have shown that both is correct:

  • the root jail is a security improvement
  • there exist numerous other improvements, many of them probably more efficient than the jail

1 comment:

Matt said...

I completely agree that fewer attack vectors is better than more, especially when there's a simple task that can be performed to get us there. I think that Bruce Schneier would argue that the equation for weighing security improvements should also account for the cost (time and money) invested in the solution. Maybe

S_impr = (S_curr - S_jail) + cost

Then an

if S_impr < S_curr then Win()

or something similar. But yea, I think chrooting services is an improvement most of the time. I run bind chrooted anyway, for that purpose.

off topic from this post, but I've been evaluating various syslog packages, both for my blog and for my company, and I really like the feature set of rsyslog (and the price). I'll be implementing it in a lab sometime in the coming weeks, so I just wanted to say thanks for writing a program like this. Before I found rsyslog, I was mired between choosing vanilla syslogd and syslog-ng. I'm glad there's another choice.

rsyslog 8.31 - an important release

Today, we release rsyslog 8.31. This is probably one of the biggest releases in the past couple of years. While it also offers great new fu...