_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