Hi all, please let me jump into the middle of that discussion.
Maybe it helps if someone else comments. From my (external) point of view, it looks like your arguments hit more or less the same targets, but it also looks like you seem to apply different co-notations to things. So let me try to formalize things a bit. 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 exists 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 show 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 And if I got you right, I think your arguments meant exactly this ;) For rsyslog as a project, this also means we need to weigh security measures against functionality. Based on this discussion, I wonder if it would be a useful undertaking to try document at least the security options at hand and try to provide some helpful notes for those that are not so deeply knowledgeable about these issues (including me, someone who is always surprised by the numerous ways people find to circumvent what one has considered to be secure ;)). Feedback is appreciated. Rainer > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:rsyslog- > [EMAIL PROTECTED] On Behalf Of RB > Sent: Saturday, November 22, 2008 11:49 PM > To: rsyslog-users > Subject: Re: [rsyslog] rsyslogd security questions/comments > > On Sat, Nov 22, 2008 at 04:17, Jan-Frode Myklebust <[EMAIL PROTECTED]> > wrote: > > Did you see the comment from Rainer about the secpath-replace > property? > > I think that proves my basis is not flawed. The chroot here protects > > against code flaws, or configuration flaws that could otherwise give > > attacker the possibility of overwriting system files. > > I most certainly did, but all the secpath-replace property protects > against is an administrator foolishly trusting unvalidated data from a > remote host to generate file paths. Chroot does not protect against > code flaws, full stop. That is the continuing flaw in your argument. > Chroot only prevents code flaws from affecting anything _outside_ of > the chroot environment. > > > Also you pointing at "most exploits bring their own executable .. > operate > > purely in-memory" argument is flawed when I'm arguing for chroot > being > > *more* secure. Not 100% secure against all flaws, but *more* secure > than > > a non-chrooted process. > > You mistake what I am arguing - there is no question that chroot() > helps protect the host system's files. What it does _not_ protect > against is abuse of anything within the chroot(). Your statement was: > > > so I would argue that my sensitive syslogged data is more secure in a > > chroot environment > > If your log data is being stored inside that chroot, you are utterly > wrong. Please actually understand what chroot() does before you > continue making wild, unfounded statements. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
