Le 17/01/2018 à 21:43, Anders Magnusson a écrit :
Den 2018-01-17 kl. 20:20, skrev Mouse:
Maybe group kmem read, but that might require more elevated
privileges in the programs that uses ksyms.
What program uses ksyms now that doesn't require at least group kmem?
You cannot give up kmem read privileges when calling ksyms read
routines.
I don't see why not - or, at least, I don't see the ksyms change as
being relevant. Just read /dev/ksyms at startup (at the same time as
you open /dev/kmem, probably), before dropping group kmem. Isn't that
all this change (making /dev/ksyms 440 root:kmem) requires?
You still have to call library functions with elevated privileges compared
with today.
Not really. libkvm uses ksyms(4) only when the file opened is the active
kernel. A tool that needs to see the symbols of the kernel is a tool that
will then use kmem(4); and since /dev/kmem is already 440 root:kmem, the
tool already needs to be in $g_kmem.
So, making /dev/ksyms 440 root:kmem should not break anything.
If it does, then there's a bug in the offending tool in the first place.
For the record: I haven't yet started closing all the paths that leak kernel
addresses, but basically ksyms(4) is one of them.
Maxime
