[rsbac] feature request: rsbac restrictions in address accessing to /dev/mem.

[Javier J. Martínez Cabezón]

Do you want mean that you should do the check as for example in READ
or WRITE instead of OPEN? could be done in a way that if required
write could be done too? ( I'm looking for good reasons to write in
raw mode in memory areas, as maybe memory corruption).
For example: writting to /dev/mem you make:

-one open call to /dev/mem
-one seek and one read or write call

so if access granted to /dev/mem then
if request == READ  AND address == within_video memory
then if not READ right in SCD.videomem
return EPERM;
if request== WRITE AND address ==within_video memory
then if not WRITE right in SCD.videomem
return EPERM;
else do_whateveryouwant

if request == READ AND address==out_video_memory
then if not READ right in SCD.kmem
return EPERM;

if request == WRITE AND address==out_video_memory
then if not WRITE right in SCD.kmem
return EPERM;
else do_whatever_you_want.

Do you want mean something like this?
2009/1/15 Amon Ott <ao en rsbac.org>:
> Am Dunnersdag 15 Januor 2009 schrieb Javier J. Martínez Cabezón:
>> Enabling global access restrictions to /dev/mem must not be a good
>> idea, If you want to make an forensic analysis (for example rebuilding
>> task with the  task_struct linked list or rebuilding it with the
>> task_struct_cachep using cache objects you will need to reach any
>> address in /dev/mem. It would be great to have one rol forensic_r that
>> only him could reach to all the address in /dev/mem and get the other
>> ones filtered to only video memory don't you think?
>
> Currently, we have target SCD kmem. We could add SCD video or videomem and use
> that target, if the access is to video area.
>
> It would take some changes in the current way of interception, because now we
> check at open. Nothing problematic, though.
>
> Amon.
> --
> http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22
> _______________________________________________
> rsbac mailing list
> rsbac en rsbac.org
> http://www.rsbac.org/mailman/listinfo/rsbac
>