[rsbac] 2.4.12+ rsbac+freeswan+grsec

Amon Ott ao at rsbac.org
Wed Jun 18 17:26:36 MEST 2003


On Wednesday, 18. June 2003 01:15, Bencsath Boldizsar wrote:
> Possible question:
> 
> In my 2.4.19 i had problems joining rsbac and grsec thus both wanted to
> use entry.S for it's function symbol. Now there seems to be that grsec no
> longer uses that part of the symbol table. Is it fully o.k.? (And if they
> don't need it, why does rsbac need it? No- don't answer, I know it's
> *magic*, so it's just a remark )

RSBAC uses the field reserved for syscall sys_security. Maybe grsecurity now 
uses devices or whatever.

> Amon:
> Most problems from patching the kernel both rsbac and grsec is due to that
> both want to patch the same area.
> 1. It would be nice to let the official kernel change the parts where
> if (something) do_something; ->
> if (something)
> {
> do_rsbac_something...
> do_grsec_something...
> }
> command_A
> command_B
> 
> #ifdef rsbac...
> #endif...
> 
> /*INSERT SECURITY _IDENTIFIER PATCH HERE
>   _ID
>   _ID (multiple lines for patch environment finding)...
>   _ID
> /*/
> 
> command_C
> 
> 
> ... so the next patch would find the indentifiers again, and inserts their
> code perfectly?

The problem is that you never know where some project might want to patch, so 
you would need tons of placeholders.

The official solution for the patching problem are Linux Security Module 
hooks everywhere deep inside the Linux specific code. Very Linux specific, 
though, and you must write an extra function for every hook you want to use.

Amon.
--
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22


More information about the rsbac mailing list