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

Javier J. Martínez Cabezón <[email protected]>
Newsgroups gmane.linux.rsbac
Message-ID <[email protected]>
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 <[email protected]>:
> 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
> [email protected]
> http://www.rsbac.org/mailman/listinfo/rsbac
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.