YAY! Site is now up to date! Now I can continue to work on the code! :)
Welcome to the home of USRBAC. USRBAC is yet another Mandatory Access Control system on top of Linux. This is a unique project, but is similar to grsecurty, RSBAC, and SELinux. USRBAC is aimed at providing the hooks necessary to create a userspace implementation of an access control daemon compliant with the RBAC standard for Access Control.
The difference with USRBAC is that it does not rely heavily on kernelspace decision making. Logging and decision making are done by a process connected to the kernel through a device interface. This interface is event driven and ioctl() handled.
Hooks inside the kernel relay to the hooks to the daemon. If there is no daemon, or the current task is the daemon or is related to the daemon by having inherited CAP_SYS_ACLD, then these hooks return without doing any checks, and simply do not raise any security concerns (NOT_DENY).
For a more complete description of the goals, design and implementation of USRBAC, please see the theory page.
Maybe later. For now I don't know if I'll ever get this thing off the ground. You want to donate? Donate some code, give me some suggestions, or do the easiest thing: Refrain from sending me stupid e-mails like "This is an awesome project! Can't wait to see it finished! When are you gonna be done!"
No. In the event that I actually get something working and start actually taking compensation, which I'm not too keen on, I do with the money what I wish. I might spend it, might buy myself a new machine to test on (can you say G5?), might just donate a chunk of it to another project, might spend some of it on my college education, whatever.
My point is that my work here is volunteer work, and that if I ever do decide to take donations, it will be voluntary donations, which means I write it on my tax forms in April as income.
Sure. irc.freenode.net #usrbac will be fine. Feel free to hang around.
My plan of action is to work on the site and use it to get down the general structures and functions I'm going to use as I build the Implementation page for rbacd. Meanwhile I'll code shmdecode.c and functions.h. Then I'll work on finishing up the rest of the structures I need, code decoders in shmdecode.c, then copy it to shmencode.c and alter the functions to be encoders.
Once that's done, I'll continue working on rbacd. When I get far enough, I'll start compiling the code against test cases. Then I'll ask someone to code the kernel driver (KURBAC) for me, because I'm likely capable of doing it with help, but frankly, I'm just lazy.
Once every part of the rbacd is coded, I'll have the kernel driver (KURBAC) coder help me with getting the ioctl() interface up in the rbacd and begin coding the administrative tools. I'll also be looking for help to autoconfize rbacd.
Once rbacd is working and the kernel hooks (KURBAC) are done, I'll be doing simple test cases with a debugger using the kernel interface, with a relaxed kernel that'll printk() instead of panic() when I kill off the fake acld.
When I determine that the kernel and rbacd both work, I'll release a test version of rbacd, KURBAC, and the usrbac-tools. Then I'll wait for bug reports, if any. I'm expecting some bugs, but my style is to test as often as possible and go bug-hunting before releases.
Once KURBAC, rbacd, and the usrbac-tools are working fine (no bugs), I'll begin work on the part of the project that interests me: URPID. The entire URPID system will be a separate library, which can be disabled at runtime. A configuration file will contain urpid settings (on, off, allon, alloff), which allow you to set the default URPID settings to on or off, or set ALL URPID settings to on or off. Individual users and roles will have URPID settings of 'default', 'on', or 'off'; the allon and alloff settings override these.
URPID will probably remain in a state of continuous development; however, when particularly useful results appear, they will be noted down, and there will be profiles that set URPID up to run as these.