Or to concisely reiterate the points that have been made:
(1) doing anything by path is inherently exploitable via a race between path reresolution and other code and/or signatures being moved into place
(2) code can be loaded from places which are not representable as per code-object files, and therfore not amenable to file-based signature checks
(3) "boot root" code, which loads a kernel and a set of pre-linked kexts will load them from many possible locations which do not match the root volume once mounted. Apple RAID is one place where thus happens; net install is another, tftp netboit is yet another
(4) no vnode reference is retained for KEXT files, even if they are actually accessible as files (see #1)
(5) if a vnode reference were retained, it would be as a backing object; Mach VM has an effective "reverse copy on write", which means the vm_object_t for something is not necessarily the vm_object_t you would get on reload (this is in general more applicable to signed binaries for processes rather than KEXTs, as KEXTs are not paged). Still, once backed by a physical page, unless you check the contents of that physical page or force a backing rationalization, the file contents that loaded the original contents of the page before it was adulterated and the signature will still claim the page is valid.
If you can say what you are attempting to accomplish via doing this, Mike and I can probably give you a better alternative of how to accomplish it, or if not, the right way to phrase a feature request so that what you get ends up doing what you want, rather than what you say you want by clinging to a particular solution rather than describing the problem.
-- Terry
On Oct 17, 2009, at 12:39 PM, Michael Smith <
email@hidden> wrote:
On Oct 16, 2009, at 9:48 PM, Rustam Muginov wrote:
What i am trying to do is:
enumerate all loaded kexts and check if they are codesigned and if signing authority is by apple.
As far as I understand this is impossible to check codesign info of the kext loaded into kernel from userspace, so i am trying to check the on-disk binaries.
There is no binding relationship between the file on disk and the object that was loaded into the kernel. Be careful about what assumptions you make in this case; if you are trying to prevent someone from having any non-Apple extensions loaded, it would be trivial to move a replacement kext with the same bundle identifier into place on disk to replace a non-Apple kext once it has been loaded.
If you want to establish the signing provenance of loaded extensions you should request an API for this by filing a bug.
= Mike
On Oct 17, 2009, at 7:58 AM, Michael Smith wrote:
Is it possible to locate the binary for an arbitrary kext, which may
be outside of /System/Library/Extensions folder?
kextfind utility, as far as I understand, performing folder iteration
and need to scan all the disk if kext binary is not located at the
standard place.
In the general case, no. Loaded kexts don't hold a reference on the file that they were loaded from, so the kext bundle may be (and often is) moved or deleted immediately after the kext is loaded.
The kext may also not have ever come from a regular kext bundle; it may have been loaded via one of several other mechanisms.
If you were to tell us a bit more about the problem you're trying to solve, we might be able to offer some more constructive suggestions...
= Mike
--
The lyf so short, the craft so long to lerne -- Chaucer
--
Sincerely, Rustam Muginov
--
The lyf so short, the craft so long to lerne -- Chaucer