[rsbac] A few comments/questions on RSBAC

tvrtko.ursulin@sophos.com tvrtko.ursulin at sophos.com
Wed Jul 6 18:22:14 CEST 2005


Hi all,

[btw, kernel 2.6.11, RSBAC 1.2.4]

I just started looking at RSBAC two days ago so excuse me if something I 
say might be completely wrong.

1. There is a rsbac_kmalloc function which allocate in this way:

#if KERNEL >= 2.6
kmalloc(size, GFP_ATOMIC)
#else
kmalloc(size, GFP_KERNEL)
#endif

Why? It looks totally wrong and extremely hackish. It also leads me to 
belive that request hook must not sleep, which I have confirmed with 
kernel debugging options. Of course, because of that, the whole usability 
is questionable.

The comment for that function is also wrong, it says that it will always 
allocate GFP_KERNEL.

2. However, DAZ module which is shipped together with RSBAC does sleep in 
it's request hook by waiting on a event, of course it will do that since 
it must communicate with userspace.

3. DAZ subdirectory also holds two completely identical files, 
dazuko_rsbac.c and dazuko_main.c. One of them is not used. There are more 
unused files in there (FreeBSD?!).

4. RSBAC source code is full of enums, unions and structures named like 
struct rsbac_something_t. They are not typedef-ed, so why they have _t 
suffix? I thought that it is a convention that typedef-ed type should have 
_t added to them and this is confusing.

Having noticed all this by only briefly looking at the code, how mature 
and stable do you consider RSBAC to be currently? Especially on 2.6 
kernels?

Regards,
Tvrtko



More information about the rsbac mailing list