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

starting with rsyslog v4…

Finally, rsyslog v4 is materializing. Yesterday, I released the first devel version that is named 4.1.0. This starts a totally new branch. I decided to finally move on to v4 because I am enhancing performance quite a bit and this causes a number of big changes to the core engine as well as many modules. So rather than doing all of this in v3, I thought it is a good time to move to a new major version.

I expect that the new code will de-stabilize the project for some time and so I have now a feature-rich v3-stable release which will be available to everyone, at the price of less performance. That doesn’t mean v3 is slow, but v4 is even much faster. So I can finally begin to experiment a bit more with the new v4 branch and don’t need to think too hard that I may be introducing changes that are hard to roll into a stable within a reasonable time frame.

As far as the first v4-stable is concerned, I do not expect one to surface before February 2009 and, obviously, it will be not as stable as v3-stable is.

So the game is starting once again, and I hope you enjoy it ;)

Windows 2008 Event Log…

Did you know – Windows 2008 has a much changed event log format. There are new APIs and formats all over that operating system. The first incarnation of the new logging system was seen in Windows Vista, but, being a workstation OS, it did not receive much attention from the corporate world.

When Vista came out, we at Adiscon immediately introduced the new event log monitor V2 service in MonitorWare Agent and EventReporter. That service worked well, but not many customers ever used it (who really monitors the workstation event logs…).

With the rise of Windows 2008 Server, we saw a notable increase in interest. And we finally got questions! While we always supported all properties, some of the former event log monitor properties are not available under the Windows 2008 event system. A number of customers asked if we could map them. Makes an awful lot of sense, especially if you have log analysis scripts that expect those fields. So I went to development (no longer working on Windows myself these days) and asked what we could do. I thought it would be trivial. But it wasn’t. Some mappings seem to have really hard, plus we got the impression (from lack of discussion and coverage) that we are probably among the first to ever work in this area). But nothing can stop a good programmer ;)

So I was quite happy to learn today that we have finally manage to include a full emulation of pre-Windows 2008 event properties. The code currently is in beta, and is available both for MonitorWare Agent and EventReporter.

I am especially happy as the new emulation also makes it far easier for phpLogCon to work with Windows events in a consistent way. Not to mention that I like happy customers ;)

regular expression tool for rsyslog

Regular expressions are quite powerful, but the syntax in rsyslog is, well, not easy to use. Also, as we have seen, the usual regex check tools don’t work always well with rsyslog’s POSIX expressions. I have created a web-based regular expression checker/generator today. It is more or less finished, but of course needs fine-tuning.

If this tool turns out to be useful (judging on comments and access count over the next weeks), I will probably do some other online tools aiding in config generation. This will be part of the overall effort to make it easier to unleash rsyslog’s full potential (all too often people simply do not know what magic they could do ;)).

New SyslogAppliance Web Site Design…

The joy of being part of a smaller team is that you get exposed to things that you otherwise would never be. Today, this hit me in the form of the redesign of the SyslogAppliance web site. We set up a very basic site when we announced the initial beta a few days ago and now we thought to upgrade it at least a bit. I ended up writing the new web site copy. I personally like the new site. It still is a very small one, with not yet that many information available about the syslog appliance project. But I think it has evolved rather quickly. Anyhow, I’d appreciate feedback from my readers. If you have a few minutes, I’d appreciate if you could have a glance at and let me know what you think.