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 >