Not working for me - Githubissues

frank-laemmer commented 2 years ago

Thanks for the nice tool and the blog post. It's unfortunately not working on my computer. Not sure what you would require as debugging info?

I followed the install guides. No errors there. After restart / upgrade the line auth sufficient pam_tid.so in /etc/pam.d/sudo was missing and it didn't asked for touchID.

macOS 12.1 Beta (21C5039b)
m1 Apple Silicon

Random other ideas

Link blog post from readme
Uninstall guides :)

BirkhoffLee commented 2 years ago

hi frank - thank you for reporting the issue, i have updated README accordingly. could you provide:

output of ls -l /Library/LaunchDaemons/me.birkhoff.persistent_pam_tid.plist after system upgrade
output of ls -l /usr/local/bin/pam-tid-installer after system upgrade

BirkhoffLee commented 2 years ago

and check these two log files /tmp/pam-tid-installer.stdout.log /tmp/pam-tid-installer.stderr.log as well

frank-laemmer commented 2 years ago

Will do with the next update. I am under the impression that this also happens after restart / reboot (not system update).

frank-laemmer commented 2 years ago

I have some trouble re-producing the issue currently. It seems to survive restart, which was not the case before, as far as I recall. I plan to test with next macOS software update.

frank-laemmer commented 2 years ago

After system upgrade macOS 12.1 (21C51):

ls -l /Library/LaunchDaemons/me.birkhoff.persistent_pam_tid.plist
-rw-r--r--  1 root  wheel  672 Dec  7 20:09 /Library/LaunchDaemons/me.birkhoff.persistent_pam_tid.plist

ls -l /usr/local/bin/pam-tid-installer
-rwxr-xr-x  1 root  admin  282 Dec  7 20:09 /usr/local/bin/pam-tid-installer

/tmp/pam-tid-installer.stdout.log seems to be empty. /tmp/pam-tid-installer.stderr.log has this:

sed: /etc/pam.d/sudo: Operation not permitted
sed: /etc/pam.d/sudo: Operation not permitted

Then I re-installed the persistent-pam-tid tool.

The line auth sufficient pam_tid.so in /etc/pam.d/sudo is still missing. I added the line manually (if I understand the tool correctly, it will only add the line during startup not by installing).

I restarted the computer. sudo via touch ID is still possible. Not sure if that is standard behavior or because of this tool. I am under the impression, that even after restart (not software update) the Touch ID sudo was gone.

Thanks for creating the tool one more time!

BirkhoffLee commented 2 years ago

My best guess is that macOS Monterey has introduced new changes that breaks the standard way of modifying /etc/pam.d/sudo, or there's a change to LaunchDaemon. I'll need to upgrade my Macbook to actually test out what;s going on, and I'll give you an update on this issue thereafter.

BirkhoffLee commented 2 years ago

So apparently the kernel is preventing sed from modifying /etc/pam.d/sudo. I don't get how it get sandboxed (I'm not a specialist at macOS though): System Policy: sed(10825) deny(1) file-write-create /private/etc/pam.d/.!10825!sudo

Update: it's TCC that is blocking write access to the file:

...
21-12-14 20:03:40.555 TCC         REQUEST: tccd_uid=0, sender_pid=150, sender_uid=0, sender_auid=-1, function=TCCAccessRequest, msgID=150.150
21-12-14 20:03:40.555 TCC         REQUEST_MSG: msgID=150.150, msg={
    service="kTCCServiceSystemPolicySysAdminFiles"
    TCCD_MSG_SPI_VERSION=2 (0x2)
    user_tccd_unavailable=true
    function="TCCAccessRequest"
    TCCD_MSG_MESSAGE_OPTION_REQUEST_RECORD_UPGRADE_POLICY_POLICY_KEY=1 (0x1)
    TCCD_MSG_REQUEST_TYPE_KEY=0 (0x0)
    TCCD_MSG_MESSAGE_OPTION_REQUEST_PROMPT_RIGHTS_MASK_KEY=5 (0x5)
    TCC_MSG_REQUEST_AUTHORIZATION_SUBJECT_CREDENTIAL_DICTIONARY_KEY={
        TCCD_MSG_CREDENTIAL_AUTHENTICATOR_TYPE_KEY=1 (0x1)
        TCCD_MSG_CREDENTIAL_AUTHENTICATOR_AUDIT_TOKEN_KEY={pid:69241, auid:-1, euid:0}
    }
    TCCD_MSG_MESSAGE_OPTION_REQUEST_USAGE_STRING_POLICY_KEY=2 (0x2)
    TCCD_MSG_MESSAGE_OPTION_REQUEST_PROMPT_POLICY_KEY=2 (0x2)
    TCCD_MSG_ID="150.150"
}
21-12-14 20:03:40.555 TCC         Constructed 'accessingProcess' from indirect_object_token in message from <TCCDProcess: identifier=com.apple.sandboxd, pid=150, auid=0, euid=0, binary_path=/usr/libexec/sandboxd>
21-12-14 20:03:40.555 TCC         AttributionChain: responsible={<TCCDProcess: identifier=com.apple.bash, pid=69218, auid=0, euid=0, responsible_path=/bin/bash, binary_path=/bin/bash>}, accessing={<TCCDProcess: identifier=com.apple.sed, pid=69241, auid=0, euid=0, binary_path=/usr/bin/sed>}, requesting={<TCCDProcess: identifier=com.apple.sandboxd, pid=150, auid=0, euid=0, binary_path=/usr/libexec/sandboxd>},
21-12-14 20:03:40.556 TCC         per-user tccd is unavailable; handling in system tccd; service: kTCCServiceSystemPolicySysAdminFiles
21-12-14 20:03:40.556 TCC         handle_TCCAccessRequest: incoming client: 150, for: <private>
21-12-14 20:03:40.556 TCC         Constructed 'accessingProcess' from indirect_object_token in message from <TCCDProcess: identifier=com.apple.sandboxd, pid=150, auid=0, euid=0, binary_path=/usr/libexec/sandboxd>
21-12-14 20:03:40.556 TCC         AttributionChain: responsible={<TCCDProcess: identifier=com.apple.bash, pid=69218, auid=0, euid=0, responsible_path=/bin/bash, binary_path=/bin/bash>}, accessing={<TCCDProcess: identifier=com.apple.sed, pid=69241, auid=0, euid=0, binary_path=/usr/bin/sed>}, requesting={<TCCDProcess: identifier=com.apple.sandboxd, pid=150, auid=0, euid=0, binary_path=/usr/libexec/sandboxd>},
21-12-14 20:03:40.556 TCC         AUTHREQ_CTX: msgID=150.150, function=TCCAccessRequest, service=kTCCServiceSystemPolicySysAdminFiles, preflight=yes, query=1,
21-12-14 20:03:40.556 TCC         AUTHREQ_ATTRIBUTION: msgID=150.150, attribution={responsible={<TCCDProcess: identifier=com.apple.bash, pid=69218, auid=0, euid=0, responsible_path=/bin/bash, binary_path=/bin/bash>}, accessing={<TCCDProcess: identifier=com.apple.sed, pid=69241, auid=0, euid=0, binary_path=/usr/bin/sed>}, requesting={<TCCDProcess: identifier=com.apple.sandboxd, pid=150, auid=0, euid=0, binary_path=/usr/libexec/sandboxd>}, },
21-12-14 20:03:40.557 TCC         IDENTITY_ATTRIBUTION: /bin/bash[150]: from cache: = /bin/bash, type 1 (367/536)
21-12-14 20:03:40.557 TCC         AUTHREQ_SUBJECT: msgID=150.150, subject=/bin/bash,
21-12-14 20:03:40.557 TCC         Refusing TCCAccessRequest for service kTCCServiceSystemPolicySysAdminFiles from client Sub:{/bin/bash}Resp:{<TCCDProcess: identifier=com.apple.bash, pid=69218, auid=0, euid=0, responsible_path=/bin/bash, binary_path=/bin/bash>} in background session
21-12-14 20:03:40.557 TCC         AUTHREQ_RESULT: msgID=150.150, authValue=0, authReason=5, authVersion=1, error=(null),
21-12-14 20:03:40.557 TCC         REPLY_MSG: msg={
    auth_value=0 (0x0)
    result=false
    auth_version=1 (0x1)
    auth_reason=5 (0x5)
}
21-12-14 20:03:40.557 TCC         REPLY: (0) function=TCCAccessRequest, msgID=150.150
21-12-14 20:03:40.557 TCC         RECV: synchronous reply <dictionary: 0x7f8c3d010490> { count = 4, transaction: 0, voucher = 0x0, contents =
    "auth_value" => <uint64: 0x7d002119dab45367>: 0
    "result" => <bool: 0x7ff8552e21a0>: false
    "auth_version" => <uint64: 0x7d002119dab44367>: 1
    "auth_reason" => <uint64: 0x7d002119dab40367>: 5
}
21-12-14 20:03:40.558 sandbox     disposing: 0x7f8c3d014dd0(OS_tcc_authorization_record)
21-12-14 20:03:40.558 sandbox     disposing: 0x7f8c3d207fd0(OS_tcc_message_options)
21-12-14 20:03:40.558 sandbox     disposing: 0x7f8c3d208430(OS_tcc_credential)
21-12-14 20:03:40.558 sandbox     kTCCServiceSystemPolicySysAdminFiles denied by TCC for sed
21-12-14 20:03:40.558 kernel      sandboxd rejected approval request from sed for kTCCServiceSystemPolicySysAdminFiles (/private/etc/pam.d/.!69241!sudo): denied

frank-laemmer commented 2 years ago

Thanks for the updates. That correlates with my observations. sudo mode removed after simple restart again.

On the other side, a fingerprint is pretty easy to fork and probably not as secure as a secure password. But having a secure sudo password is also a hustle when to be typed often. Hm.

BirkhoffLee commented 2 years ago

Yes, after some investigation it seems Apple has restricted access to /etc/pam.d/sudo in TCC on macOS Monterey, I have currently no idea how this could be fixed :(

rluvaton commented 2 years ago

Wanted to use this tool and saw this issue, is this only for sed?

I have an ansible playbook to setup my dev machine and in there I add the pam_tid.so to /etc/pam.d/sudo if missing, and it's working (until now I tested it only in a VM...)

I have M1 Max if interested and Monterey (the VM is also Monterey)...

rluvaton commented 2 years ago

After debugging and trying to solve this for the past 4 hours and I found something that may help but I couldn't apply it to our case - macOS processes — What to do when your daemon gets blocked by permissions dialogues.

The problem I found out is that like it says in the article, we run it as root and there is no GUI session* so the user is not prompt for the TCC GUI, even when I tried to add the binary to the Full Disk Access in the privacy settings it didn't work.

if someone want to try to solve this I think the linked link below is the best option we have

A possible solution is to add the /usr/local/bin/pam-tid-installer file to the files that run on startup and add before any sed - sudo

I've also tried to set suid to the file so any user can run it as root (and I limited write access to root only) but it didn't work either...

And also I've tried to change the file /etc/pam.d/sudo using Swift but I couldn't gain permission either (I don't really know Swift)

BirkhoffLee / persistent-pam-tid

Not working for me #1

Random other ideas