Todd C. Miller <[email protected]> wrote: > On Wed, 22 Jan 2020 15:17:32 +0100, Martin Pieuchot wrote: > > > Just like dt(4) or mem(4), ksyms(4) allows userland to read kernel > > addresses. > > > > Diff below makes `allowkmem' a requirement for opening the > > pseudo-device. > > Won't this break everything that uses /dev/ksyms? The default for > allowkmem is 0. > > Furthermore, ksyms doesn't provide kernel _addresses_, it provides > kernel _symbols_. There shouldn't be anything available via > /dev/ksyms that is not also available from reading the booted kernel.
Well, symbols are resolved to contain addresses. Especially in text segment, immediately you know text gadgets. Knowing layout of text, you can determine .o linkage order for a correctly-dated-kernel, and therefore estimate data segment layout for data location attacks. You can see where an object would be, but you can't read the object. This is unlike dt where you can see the object and via parameter inspection deeply reason about the value plaed at object addresses. However, the permissions look good: -rwx------ 1 root wheel 18480588 Jan 21 08:22 /bsd* crw-r----- 1 root kmem 50, 0 Jan 14 23:39 /dev/ksyms We don't have any setgid kmem programs anymore, so the disclosure is limited to root who can read the kernel. Having layed out all the arguments, I agree with Todd that ksyms doesn't seem to require further protection.
