[rsbac] Re: rsbac 1.2.3

Amon Ott ao at rsbac.org
Tue Jun 29 16:03:10 CEST 2004


On Dienstag, 29. Juni 2004 15:06, by way of Amon Ott <ao at rsbac.org> wrote:
> On Tue, Jun 29, 2004 at 08:52:35AM +0200, Amon Ott wrote:
> > On Dienstag, 29. Juni 2004 00:02, spender at grsecurity.net wrote:
> > > I would like credit for discovering the jail vulnerabilities that you 
> > > recently fixed.  I would also like credit for the regression suite 
that 
> > 
> > Since you only claimed to others that there might be some, but did not 
> tell 
> > any details or proof anything, I will take the credit myself for 
finding 
> > and fixing them. 
> 
> No, not that there might be some, but that there ARE (and still are) 
> several.  I gave them the code to find these *vulnerabilities* even with 
> instructions on how to modify it to test with RSBAC.  What the else do 

"Them" seems to be Albeiro, who already answered himself. Since I never 
have been personally notified by you and never saw these instructions, I 
will not answer to them.

I got some test code without copyright, ownership and license, and I 
wrongly assumed it to be under GPL. As the author has come forward and 
stated that this is not the case, I have removed this code from the RSBAC 
package and uploaded the new version. I will also state this fact on the 
official RSBAC mailing list.

> you want?  You want me to fix your vulnerabilities too?

Certainly, I expect you to rather fix GRSecurity bugs than RSBAC bugs.
 
> use all the modules of RSBAC.  If you say you're providing a "jail" 
> environment, and I can easily execute code outside of that "jail," it's 
> a vulnerability.  Don't try to spin this.  CVE and every other database 
> will happily make an entry for each one of the vulnerabilities.  Bugtraq 
> and every other mailing list will happily recognize it as a 
> vulnerability.

You still do not get my point: The RSBAC JAIL module has some 
functionality, which has been written down explicitely in its module 
description. Your definition of the term "jail" and expectations when 
using the code are not relevant here.

All this hassle would have been avoided, if you had followed the common 
practice to notify the author and provide details.
 
> > The code has been taken from a project, which I thought to release free 
> > software only, and has been modified for RSBAC use. If this is not the 
> > case, I will remove the code and make a public statement about the 
> mistake 
> > about an unclear licence.
> 
> The license has been modified to read as follows:
> 
> All code in this directory is (c) Brad Spengler, 2004
> Because RSBAC developers blatantly rip code unlawfully and do not give
> credit for reporting multiple vulnerabilities in their system, this code
> may not be modified or redistributed.  It may be used only for the
> purposes of verifying a grsecurity installation where RSBAC is not 
> present in the kernel.

Thanks for correcting your fault of not supplying author, copyright and 
license. The wording is not correct, but it does not matter to me. Please 
do not forget to remove the code from your Website, because it may not be 
redistributed.

I have ripped all code derived from the tarball I received (before your 
licence note, BTW) from the RSBAC tools package's contrib dir and uploaded 
the new packages.
 
> > I would be glad to get any of your claims detailed and proved instead 
of 
> > making unproven claims. If you think it fine to release bugs to the 
> public 
> > instead of notifying the authors, this is something I would classify as 
> > dishonest.
> 
> Again, as seen from above, I did more than my share to report these 
> holes.  If i had not, how would you have found them?  Are you also 
> claimining to have not found them by using my code?  Just because you 
> don't like someone's method of reporting vulnerabilities doesn't give 
> you the right to be a jackass.  In fact, I had even discussed the 
> vulnerabilities in explicit terms on IRC with albeiro.  It's hilarious 
> to me when I discover multiple vulnerabilities in someone's system and 
> they still think I'm lying about there being additional holes.

OK, stating the facts once more as I see them:

- I did not get any details, and I do not read all IRC channels.

- I never said you were lying, I only asked for facts and details, but did 
not get any.

- I never said there were no bugs. This is software, so there are bugs. 
Every security oriented person should try to get bugs fixed instead of 
spreading claims and rumours.

- Using the regression suite, I found several things reported, which I do 
not see as bugs, and a few, which might be called bugs. Since a jackass 
said "there are several bugs, but I won't tell you more", I changed the 
code so all the wanne-be-bugs are closed, too.
(Example: it is reported as a vulnerabilty, if a program can open a dir, 
chroot, and then still access the dir. What a stupid program to do this, 
but I have "fixed" that.)

- If you believe that there are still bugs in v1.2.3, PROVIDE INFO OR SHUT 
UP.

> > Please reread your previous paragraph to find another unproven claim, 
> which 
> > should rather be shown to the author. BTW, you seem to be missing one 
> > fact: JAIL is not all of RSBAC - it is a convenient, but not an 
important 
> > module.
> 
> And you seem to be missing one fact.  JAIL can be used by itself.  It is 
> supposed to provide jail functionality.  If it does not do what you 
> claim it to do, it is a vulnerability.  Stop spinning this to avoid bad 
> publicity.

Yes, JAIL can be used by itself, and it does provide jail functionality in 
the way stated in the module description. However, this does not mean it 
provides the exact functionality you personally want it to have.

> Since you've been unwilling to do the honest thing in spite of the 
> facts, I have no choice but to file separate CVE and OSVB records for 
> each of the vulnerabilities, and notify all security lists.  You may not 
> take the security of your users seriously, but I do.

Since these rules do not seem to be common practice, I hereby officially 
ask you to stop claiming bugs without telling me or the RSBAC list and 
giving details or providing exploit code. Additionally, I ask you to stop 
spreading rumours about bugs to other people.

If you really want to send spam mails everywhere, please make sure that 
noone thinks they have been sent by the RSBAC project. Using your address 
at grsecurity.net will provide some important extra information. 
 
Amon.
-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22


More information about the rsbac mailing list