Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83 (MC830713); site vu44.UUCP Path: utzoo!watmath!clyde!cbosgd!ihnp4!houxm!whuxlm!akgua!sdcsvax!sdcrdcf!hplabs!hao!seismo!mcvax!vu44!jack From: jack@vu44.UUCP (Jack Jansen) Newsgroups: net.unix-wizards Subject: Re: Acessing kmem, how about a driver? (really UN*X security) Message-ID: <536@vu44.UUCP> Date: Thu, 27-Dec-84 05:39:56 EST Article-I.D.: vu44.536 Posted: Thu Dec 27 05:39:56 1984 Date-Received: Sat, 29-Dec-84 05:31:30 EST References: <813@druky.UUCP> <295@rlgvax.UUCP> <2242@garfield.UUCP> Organization: The Retarded Programmers Home, VU, Amsterdam Lines: 29 I was thinking of making a modified kmem driver, especially for things like 'ps', etc. It would incorporate a structure like struct pmdevs { caddr_t pm_start; caddr_t pm_esize; caddr_t pm_last; } pmdevs[] = { &u, sizeof(u), u+sizeof(u), /* U area */ &procs, sizeof(*procs), &procs[NPROCS], /* process table */ .... } Every minor device would be associated with one of the entries in the array, and would adress memory from pm_start to pm_last. In this way, you could protect every table by it's own minor h device, making superuser permission for things like 'ps' unnecesary. The 'pm_esize' gives the size of a single entry. It can be collected via a ioctl call, so the user program could for instance check whethet the size of a certain structure hasn't changed since it was compiled. Does this seem like a feasible idea? If it is, has anyone implemented it already, or something similar? -- Jack Jansen, {seismo|philabs|decvax}!mcvax!vu44!jack or ...!vu44!htsa!jack If *this* is my opinion, I wasn't sober at the time.