[rsbac] Re: rsbac 1.2.3

[spender at grsecurity.net]

> "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.

So because I didn't tell you directly, but made all information public
(it was even posted to the grsecurity forums), you refuse to give
credit to the person that actually found these vulnerabilities for you,
when you knew this is where the information and code came from?
That's incredibly dishonest.


BTW it is clear that you simply ran my regression tests and fixed only
the things that said failed, without even investigating your code further.
I just downloaded RSBAC 1.2.3 an hour or so ago and with a modified test
was able to confirm that two vulnerabilities still exist within your
JAIL code that allow a root user to break out of the jail completely.

> 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.

>From your description:

The JAIL module gives you an extended chroot facility, similar to FreeBSD
Jails.  ... From within a jail, only processes and IPC objects of the same
jail can be accessed. ... Additionally, most kernel based administration
tasks are forbidden, ...etc

These are your words.  Everything there stated is false in light of these
vulnerabilities!  How can you ignore the fact that when you say you are
providing a FreeBSD jail functionality, that the processes inside the
jail cannot access processes outside, and that the users in the jail
cannot perform administration tasks?  If you claim these things and you
provide an obscured chroot that can be broken out of trivially, *it is 
a vulnerability*.

> All this hassle would have been avoided, if you had followed the common 
> practice to notify the author and provide details.

No, the hassle would have been avoided if you did the right thing, instead
of intentionally refusing to give credit where you knew it was due simply because
you did not like my methods of revealing vulnerabilities in your code and
preferred me to hold your hand and fix your code for you.

> 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.

It doesn't matter that it was taken before my license note.  The Copyright Act
states that a work is copyrighted once it is created.  The lack of a license
meant you had no right whatsoever to modify or redistribute the code: such
permission would be granted through a license.  Though I'm not bothered by this,
what I was bothered by was that you ripped the code and didn't even bother
to attribute it (of course you managed to add your own name to it).  This
has to do with ethics and doing the honest thing.  If you use someone's code,
you attribute it.

> (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.)

What about modifying abstract unix domain sockets?  How is that not a
vulnerability?  I will agree that the fchdir example is not really a
vulnerability, though it does break the notion of a jail.

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

I'll shut up and leave the two remaining methods of breaking out of your jail
unfixed.  I'm sure your users are happy that you're more interested in
attacking people that find vulnerabilities in your code than actually
taking the time to audit it and understand what you're doing.  There are
articles you could read or old mailinglist posts or stuff about the janus
project that you could read that would reveal the blatant holes in your
code.  But attacking people is easier than this, I guess.

> > > fact: JAIL is not all of RSBAC - it is a convenient, but not an 
> important 
> > > module.

But when you claim for an individual module to provide a certain level
of security, and it fails to provide that security, it is a vulnerability.
Just because people have the *option* to use other modules that *may*
prevent the attacks does not mean the vulnerabilities do not exist.
You should tell your users that the vulnerabilities exist and that
the use of other modules may mitigate the risk.  That would be
the reasonable and honest thing, instead of hiding it behind "improvements"
on the front page.

> 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.

Again, using your words, it doesn't provide the functionality you claim
it to have.  And if you believe differently that I cannot access
processes outside of the jail with your JAIL code, which your patch
documentation claims I cannot do, set up a box and offer $2000 to someone
to break it.

> at grsecurity.net will provide some important extra information. 

Are you insinuating that this is an attempt to convert RSBAC users
to grsecurity?  I assure you that that isn't the case.  We've had a
somewhat amicable relationship prior to this.  This is an issue
of honesty and ethics.  I thought that in light of the facts you
would be willing to do the right thing, but you seem more interested
in the public image of RSBAC than the security of it.

-Brad