Re: Looking for package maintainers

I think we have some problems, some users that even with proper
documentation would see the system and will say: And now what! What
shall I protect and against whom?. Make risks analysis is hard,
complicated and require a deep knowledge about the gnu/linux
architecture. Not all has the knowledge required to do so.

Time ago I thought to make one "cracking game" with  PaX, et_dyn, ssp
and D_FORTIFY_SOURCE=2 distribution hardened with a proper security
policy to people could see what RSBAC can offers to them. At this way
RSBAC could be seen not as a "theoretical security framework nearly
impossible to implement by medium users" if not something that they
could touch and see working. At this way they could learn from us and
us from them (attack vectors for example). I think that if we do this
rsbac could be more known that maintaining packages for linux
distributions that seems not to be too much worried about security
itself (ubuntu has some packages with ssp, debian not, debian also
does not seems to like et_dyn since their performance impact... Only
gentoo seems to be serious at this point. Fedora and ubuntu are
starting now. Without et_dyn game over, ET_EXEC randomization get
removed time ago, without it MPROTECT, and PAGEEXEC/SEGMEXEC approach
are nearly useless. What PaX can do against one ret2libc attack in an
ET_EXEC binary?.

If you like the idea of the "cracking game" I have gentoo hardened
images running under VirtualBox, running rsbac svn code and with PaX
enabled (hey we could give one time passwords to crackers (identified
by their password :) ) to check local security!!!), other virtual
machine could be prepared to remote exploiting (daemons with known
bugs already exploited and thinks alike, like some daemons without ssp
but with et_dyn and viceversa others with both or none, some daemons
inside rsbac jail etc etc etc...). Some people could have a funny
afternoon trying to do those things that in "real life" they wouldn't
do and all could learn.

Imagine this: a lot of persons try to attack buggy software to get
access to the content of for example eight files, they test with them
the first countermeasures, once they had them got to the second level
of the game, to reach the content of 4 random files, UM and AUTH
controls login, sshd, and some kind of return into libc attacks (suid
ones) things gets harder. Finally we could see, how hardened apps
resisted the intrusion, how UM AUTH controls some aspects of the
intrusion, how RC works to stop the execution or arbitrary code with A
simple Trusted Path Execution with perl python controled stopped
lauching arbitrary code etc. Finally we could put reflexions about
what can we do to assure the system. All learnt :) .

PD: the idea get's derived from a rol game I'm prepearing :D



2009/1/19 kang <[email protected]>:
> Hi dear RSBAC users,
>
> The RSBAC project is currently looking for people willing to actively
> maintain RSBAC packages in various  Linux distributions.
> The best case, is if you are already a developer for a distribution of
> course.
>
> This would help greatly in RSBAC presence in the Linux world and RSBAC
> users.
>
> We already provide our own debian packaging for the RSBAC tools, which
> can be used as a base, or improved with patches.
>
> We can also provide similar "base" packages for any distribution, but we
> need people to coordinate updates and maintain them (answer bug reports
> on the distro side, etc).
>
> The kernel packages can however be more or less complex depending on the
> distribution and security updates are very frequent.
>
> On the "plus" side, you will get to work out things with us, gain a lot
> more knowledge about the inner workings of RSBAC and of course, should
> any technical trouble arise, have "us" core developers as direct assistance.
>
> Thanks, please let your friends know :)
>
> kang
>
>
> ps: any distribution is good, but as they are the main ones we are
> looking for: Gentoo, Debian, Ubuntu, Fedora:p
>
> _______________________________________________
> rsbac mailing list
> [email protected]
> http://www.rsbac.org/mailman/listinfo/rsbac
>