I just picked a random syscall that, just like phys_addr(2), is rarely
used and where it makes no sense to restrict access. Since I wrote it,
it came to mind easily ;-)
> > 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.
No, before asking the question "who might use it", with the implied
"how do we restrict it", you have to take a step back and ask "does
this pose a security threat".
> 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.
You can only "hijack" if you manage to get pages unfairly. This patch
doesn't provide page-selection privileges or any other memory-related
privileges.
Look at it this way: any ordinary process can "hijack" memory by
calling malloc(3)!
> * Hashtables based on physical addresses can be exploited.
Exploit what?
> * Getting the amount of memory in the machine regardless of the
> setrlimits of the process.
This patch doesn't give any privileges. I can't allocate more memory
with it, no matter what.
> * Getting some information about the "state" of the memory-management
> in the kernel. Thus it could reduce the effectiveness of setrlimit.
No. Again, this patch *only* tells you what the kernel gave you. You
get no extra privileges.
> 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.
Since there is absolutely no indication that this patch can compromise
security, it should be completely unrestricted. Only if it is shown
(by experiment or sound theory) to pose a potential security threat
should it be restricted.
The default should always be unrestricted.
> > 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 ;-)
Sorry, bad choice. How about CAP_GETUID_ALLOWED?
Regards,
Richard....
-
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