I created kernel extension for mac high sierra.
When i load kernel extension file in high sierra user should allow from security & privacy.
How can i verify that user allowed my kernel extension from security & privacy?
Is there any file in which user allowed kernel extension detail are stored.
The information about approvals is stored in sqlite3 database:
/var/db/SystemPolicyConfiguration/KextPolicy
The table is kext_policy. E.g.
sqlite3 /var/db/SystemPolicyConfiguration/KextPolicy
select * from kext_policy;
BTW, I have no idea how much you can rely on this, i.e. whether Apple will decide to change this in Mojave or any future MacOS release.
There is also spctl kext-consent <action> command, but it does not work properly on my 10.13.6 system. Maybe this will be the "correct" approach in the future.
Related
I have developed an application for MacOS. I am including notarization process as part of its distribution. I have followed all the steps and I have run:
xcrun altool --notarize-app --primary-bundle-id "${APP_BUNDLE_ID}" --username "${APPLE_DEV_ID}" --password "${DEV_APP_SPECIFIC_PASSWORD}" --file "${DMG_PATH}"
Then I check notarization progress using:
xcrun altool --notarization-info "${notarize_uuid}" -u "${APPLE_DEV_ID}" -p "${DEV_APP_SPECIFIC_PASSWORD}
Output of it is:
RequestUUID: =<Request>
Date: 2019-05-26 09:40:34 +0000
Status: success
LogFileURL: <Log file>
Status Code: 0
Status Message: Package Approved =~ success ]]
Then I launch staple command:
xcrun stapler staple -v <dmg file>
It also ends with success:
The staple and validate action worked!
However when I extract the .app file and run:
spctl --assess --verbose ./macos/MyApp.app
./macos/MyApp.app/: accepted
According to the docs I have read it should say something like: “source=Notarized Developer ID”, right?
I am running this on MacOS Mojave 10.14.5
What am I missing??
Could someone help me?
Thanks in advance
In case someone faces the same problem I will post the solution to this:
First of all you must staple .app file not the dmg. This means you must extract the binary and staple it
Also in order to check if application has been notarized, in
`System Preferences - Security and Privacy`
Option Allow apps downloaded from: must have Apple Store and identifier developers option checked
Hope this helps
Both the app and the dmg may be notarized and stapled, seperately, one after the other. Try doing that and the error should go away.
Short answer
It could be due to an RPATH referencing a path outside the App bundle. Removing this RPATH would resolve the issue.
Inspecting log files
You can find extra information about the rejection (after trying to launch the blocked app) in the Console.app. Note that you should open the Console.app, before trying to open your blocked app, otherwise not all messages may be logged. You should look for process XprotectService in the logs of your device (i.e. choose your device in the left side bar of the Console.app). If the RPATH is indeed the problem, you should find a record like this:
XprotectService: [com.apple.xprotect:xprotect] File /path/to/your/executable/or/library failed on rPathCmd /rpath/causing/the/problem (rpath resolved to: (path not found), bundleURL: /path/to/your/bundle.app)
Inspecting these log files may give you a key to solve other issues too.
Note that I received the following information from an Apple engineer:
Gatekeeper does not inform users via UI about the specifics of the
error, though it is in the logs for developers to look at. The
notarization process is purely about a detecting malicious software
and does not replicate Gatekeeper enforcement. You still need to get
software notarized and test with Gatekeeper.
We are looking to provide better tooling for developers in the future
to pre-flight some of these common errors.
Contact Apple
If you are not able to solve your issue with the above information, you may want to contact Apple itself using the Feedback Assistant. They do not respond very quickly (~1-2 weeks), but the answers are rather to the point.
I have an HP OfficeJet Pro 8610, and a nixos host.
I can easily set up the printer in cups, using hplip and a hp:/net/... address.
But how can I set up scanning with simple-scan? It doesn't recognize the existence of the printer, neither does sane-find-scanner or scanimage -L.
I have tried running hp-setup, but that fails complaining of error: No module named enum. I have tried installing python27Packages.enum in my user environment and also in the system environment, but no dice.
Thanks,
The problem was that the nix derivation was missing a dependency; specifically on the enum package in python. Luckily, somebody else already spotted and fixed this here; one just needs to update one's nix channel to pick it up.
To use scanning in general in NixOS with an OfficeJet Pro 8610, see here.
TN2459: https://developer.apple.com/library/content/technotes/tn2459/_index.html introduces that under macOS High Sierra user approval is required for loading new third-party kernel extensions.
The kext that I would like to test has been loaded before upgraded to High Sierra, so loading the same kext after upgrade does not trigger the user approval flow which I would like to test against.
The kernel extension user consent is enabled:
$ spctl kext-consent status
Kernel Extension User Consent: ENABLED
I deleted the entry that corresponds to the kext in the kext_policy table in /private/var/db/SystemPolicyConfiguration/KextPolicy under recovery mode and restart several times. But the user approval flow is still not triggered when I load the kext.
I wonder if the policy info is cached somewhere else and if I need to clear NVRAM for my machine or tell syspolicyd to clear its cache? Or there is other things that I need to do?
In short, you have to boot in recovery mode (Mac+R) and edit the sqlite table /private/var/db/SystemPolicyConfiguration/KextPolicy.
This table is accessible in read-only mode in normal boot:
sqlite3 /private/var/db/SystemPolicyConfiguration/KextPolicy
sqlite> SELECT * FROM kext_policy;
sqlite> SELECT * FROM kext_load_history_v3;
You have to remove your entries (recovery mode) and reboot, like this (Replace 'G43BCU2T37' with your team_id):
sqlite> DELETE FROM kext_policy WHERE team_id = 'G43BCU2T37';
sqlite> DELETE FROM kext_load_history_v3 WHERE team_id = 'G43BCU2T37';
sqlite> .exit
To avoid the reboot every time, you could alter the "System Integrity Protection" configuration (in recovery mode): csrutil enable --without fs --no-internal. Now kext_policy is changeable from normal boot.
The whole procedure is described here: https://forums.developer.apple.com/thread/79172#248518.
Was able to test it using a high sierra vm. The full step of installing the vm is: https://www.howtogeek.com/289594/how-to-install-macos-sierra-in-virtualbox-on-windows-10/
I am working on uclinux porting on coldfire board M5272C3. Right now I have kernel running from RAM with romfs as my rootfile system.
I am not clear about few terms what they mean and when to use them....
Please explain me in a simplest possible manner:
Q1: What is initrd? Why we need that?
Q2: What is ramdisk? Why and where we need this?
Q3: what is initramfs? Why and where we use this?
Q4: What is ramfs? Why and where we use this?
Also please refer document/reference book for in depth knowledge of these terms....
Thanks
Phogat
A ramdisk merely refers to an in-memory disk image. It is implemented using the ramfs VFS driver in the kernel. The contents of the ramdisk would be wiped on the next reboot or power-cycle.
I'll give you details about initrd and initramfs next.
In simple terms, both initrd and initramfs refers to an early stage userspace root filesystem (aka rootfs) that will let you run a very minimal filesystem in memory.
The documentation present at Documentation/filesystems/ramfs-rootfs-initramfs.txt part of the linux kernel source tree, which would also give you a length description of what these are.
What is initrd ?
One common case where there is the need for such an early-stage filesystem is to load driver modules for hard disk controllers. If the drivers were present on the hard drive, it becomes a chicken-and-egg problem. Having these drivers as part of this early-stage rootfs helps the kernel load the drivers for any detected hard disk controllers, before it can mount the actual root filesystem from the hard drive. Another solution to this problem would be to have all the driver modules built into the kernel, but you're going to increase the size of the kernel binary this way. This kind of filesystem image is commonly referred to as initrd. It is implemented using either ramfs or tmpfs. It is emulated using a loopback block device.
The bootloader loads the kernel image into a memory address, the initrd image into another memory address, and tells the kernel where to find the initrd, passes the boot arguments to the kernel, and passes control to the kernel to let it continue the boot process.
So how is it different from initramfs then ?
initramfs is an even earlier stage filesystem compared to initrd which is built into the kernel (controlled by the kernel config of course).
As far as I know, both initrd and initramfs are controlled by this single kernel config, but it could have been changed in the recent kernels.
config BLK_DEV_INITRD
I'm not going deep into how to build your own initramfs, but I can tell you it just uses cpio format to store the files and can be configured using usr/Kconfig while building the kernel. Even if you do not specify your own initramfs image, but have turned on support for initramfs, kernel automatically embeds a very simple initramfs containing /dev/console, /root and some other files/directories.
In addition there is also a newer tmpfs filesystem which is commonly used to implement in-memory filesystems. In fact newer kernels implement initrd using tmpfs instead of ramfs.
UPDATE:
Just happened to stumble upon a similar question
This might also be useful
I have access to a remote Solaris terminal which crashes occasionally, and I have to ask someone with physical access to boot the machine up, which it does successfully. I would like to know which tools/files should I look at to find out the cause of the crash so that I can make the necessary configuration changes and avoid it in the future.
What tools you can use will depend on what version of solaris you have running and what the actual problem
is. The first thing to do is check the system console (which it sounds like you don't have access to) and the /var/adm/messages file. This file is updated with system messages and the newest will appear at the end.
Next, you can look for a system core file. If a core file is created, it would be in /var/crash/hostname where "hostname" is the name of the machine.
If you have an actual core file in the /var/crash/hostname directory, this set of commands will give you a good
string to search google with:
# cd /var/crash/hostname
Replace "hostname" with the hostname of your machine.
# mdb -k unix.0 vmcore.0
If you have multiple core files, select the most recent version.
> ::status
This should give you a panic message, cut and paste that into google and see what you can find.
For more core file analysis read this:
http://cuddletech.com/blog/pivot/entry.php?id=965