Re: code signing strategies
Re: code signing strategies
- Subject: Re: code signing strategies
- From: Jean-Daniel Dupas <email@hidden>
- Date: Wed, 31 Mar 2010 10:16:02 +0200
man taskgated can give you some clue about the requirement to access mach ports.
Le 31 mars 2010 à 06:23, Jack Howarth a écrit :
> Kevin,
> I tried...
>
> sudo codesign -s - /sw/bin/fsf-gdb
>
> and I still get...
>
> [MacPro:~] howarth% fsf-gdb ./a.out
> GNU gdb (GDB) 7.1
> Copyright (C) 2010 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-apple-darwin10.3.0".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /Users/howarth/a.out...(no debugging symbols found)...done.
> (gdb) break main
> Breakpoint 1 at 0x100000f4e
> (gdb) r
> Starting program: /Users/howarth/a.out
> Unable to find Mach task port for process-id 44895: (os/kern) failure (0x5).
> (please check gdb is codesigned - see taskgated(8))
>
> whereas 'sudo fsf-gdb ./a.out' works fine. Looking at the two binaries I see...
>
> [MacPro:~] howarth% codesign -d -vvv /usr/libexec/gdb/gdb-i386-apple-darwin
> Executable=/usr/libexec/gdb/gdb-i386-apple-darwin
> Identifier=com.apple.gdb
> Format=Mach-O universal (i386 ppc7400 x86_64)
> CodeDirectory v=20100 size=17922 flags=0x0(none) hashes=891+2 location=embedded
> CDHash=1f961159e2c4038e658298a52b2f295ff95b2266
> Signature size=4064
> Authority=Software Signing
> Authority=Apple Code Signing Certification Authority
> Authority=Apple Root CA
> Info.plist entries=6
> Sealed Resources=none
> Internal requirements count=1 size=180
>
> [MacPro:~] howarth% codesign -d -vvv /sw/bin/fsf-gdb
> Executable=/sw/bin/fsf-gdb
> Identifier=org.gnu.gdb
> Format=Mach-O thin (x86_64)
> CodeDirectory v=20100 size=25960 flags=0x2(adhoc) hashes=1293+2 location=embedded
> CDHash=99c0613857a480e69f36eacc158a2d78f2f199af
> Signature=adhoc
> Info.plist entries=4
> Sealed Resources=none
> Internal requirements count=1 size=104
>
> Is it significant that Apple's gdb has flags set to 0x0 whereas
> the fsf-gdb shows flags set to 0x2? Any other ideas to try?
> Jack
>
>
> On Tue, Mar 30, 2010 at 09:23:17AM -0700, Kevin Van Vechten wrote:
>> The behavior you describe is the result of changes in recent Mac OS X releases to restrict the use of task_for_pid and related functions that present significant security risks. The goal is to limit use of such functions to the system administrator, and the policy is enforced by the taskgated process. Code signing is required in order to verify that the binary is not maliciously changed out from under any previous approval for use of these functions. Nothing about this policy is unique to gdb.
>>
>> It's possible to generate "ad hoc" code signatures on binaries which generate all the usual checksums for the purposes of integrity checks but do not chain to a trusted authority. It's worth giving the following a try to see if it satisfies the basic requirements of taskgated (I haven't tried it myself):
>>
>> $ sudo codesign -s - /path/to/gdb
>>
>> Kevin
>>
>> On Mar 30, 2010, at 7:18 AM, Jack Howarth wrote:
>>
>>> I am trying to prepare fink packaging of the
>>> new FSF gdb 7.1 release on i386 and x86_64 fink.
>>> Unfortunately Apple's changes in 10.5.8 or later
>>> require that gdb binary be code signed (or run as root)
>>> in order to access the required Mach port for
>>> debugging code.
>>> Are their any code signing gurus here who
>>> could suggest the best approach to cope with this
>>> problem? I am hoping to implement something along
>>> these lines but am unsure if it is feasible.
>>>
>>> 1) Provide an openssl certificate bundled with the
>>> fsf-gdb fink package.
>>> 2) Provide a shell script which when run, guides
>>> the user through the steps of loading the provided
>>> certificate manually in the KeyChain application and then
>>> code signs the fsf-gdb binary from within the shell
>>> script using command line tools. My understanding is
>>> that only the creation and/or loading of the openssl
>>> certificates no longer have CLI tool access.
>>> 3) Have a postinstall script in the fsf-gdb that
>>> would check if the certificate exists in the Keychain
>>> when the fsf-gdb package is installed, reinstalled
>>> or upgraded and launch the shell script described in
>>> step 2 if not present. Otherwise it would just
>>> code sign the newly installed fsf gdb binary again.
>>>
>>> Thanks in advance for any advice on these issues.
>>> Needless to say, the FSF gdb developers were a
>>> tad miffed that this restriction popped up after
>>> all the effort to support intel darwin in the official
>>> FSF gdb releases.
>>> Jack
>>> ps It will be essential to have access to a working
>>> FSF gdb 7.1 debugger for users who want to use the
>>> upcoming FSF gcc 4.5 compiler release. There are
>>> changes in debug code generation which are incompatible
>>> with the older gdb releases.
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Darwin-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
-- Jean-Daniel
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden