Messages in this thread | | | Date | Sun, 19 Jul 1998 15:43:03 +0200 | From | Alexander Kjeldaas <> | Subject | Re: [PATCH] New phys_addr() syscall |
| |
On Sun, Jul 19, 1998 at 10:45:32PM +1000, Richard Gooch wrote: > Alexander Kjeldaas writes: > > > > I this is only useful for specialized utilities, I suggest you check > > for capable(CAP_SYS_ADMIN) in the system call. > > Sorry, I don't see the connection with capabilities. The prctl(2) > syscall is also for specialised applications (actually, the > LinuxThreads library). We don't need to restrict that either.
_I_ don't see the connection with prctl! :-)
> I see no reason to restrict access to phys_addr(2). An ordinary > (unprivileged) process can't do anything with the information other > than print it out. A userspace network driver would indeed have > privileges, but those relate to accessing hardware, they have nothing > to do with translating addresses. >
I think that in this situation it is a tradeoff between how many processes need the system-call, what the information can be used for, and what implications running a userspace network driver with CAP_SYS_ADMIN will have. Let me also say that I am not 100% sure requiring CAP_SYS_ADMIN is the right answer.
I don't think it's easy to analyze the risks so I'm a bit cautious. Some of the following _could_ be risks:
* Hijacking DMA-able memory. * Hijacking memory with "good" alignments. * Hashtables based on physical addresses can be exploited. * Getting the amount of memory in the machine regardless of the setrlimits of the process. * Getting some information about the "state" of the memory-management in the kernel. Thus it could reduce the effectiveness of setrlimit.
Now, very few processes would need this information. So what are the implications of running them with CAP_SYS_ADMIN? Assuming that the process will not use the file system, network or signals, it can run with a separate uid and it should be pretty safe.
> Shall we also add CAP_GETPID_ALLOWED? ;-) >
No, but actually we _should_ add rendom pid allocation (I have a patch, but I'm waiting for 2.3). Then we won't need CAP_GETPID_ALLOWED anymore ;-)
astor
-- Alexander Kjeldaas, Guardian Networks AS, Trondheim, Norway http://www.guardian.no/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
| |