securityd — Security context daemon for Authorization and cryptographic
securityd maintains security contexts and arbitrates cryptographic opera-
tions and Security Authorizations. Access to keychain items is routed
through securityd to enforce access controls and to keep private keys out
of user process address space. Authorization calls also communicate with
securityd to enforce rules contained in the /etc/authorization database.
All user interaction with securityd is mediated through the Security
This command is not intended to be invoked directly.
securityd was first introduced in Mac OS X version 10.0 (Cheetah) as the
« Security Server » and was renamed in 10.4 (Panther).
SHA1, SHA1_Init, SHA1_Update, SHA1_Final – Secure Hash Algorithm
unsigned char *SHA1(const unsigned char *d, unsigned long n,
unsigned char *md);
void SHA1_Init(SHA_CTX *c);
void SHA1_Update(SHA_CTX *c, const void *data,
unsigned long len);
void SHA1_Final(unsigned char *md, SHA_CTX *c);
SHA-1 (Secure Hash Algorithm) is a cryptographic hash function with a
160 bit output.
SHA1() computes the SHA-1 message digest of the n bytes at d and places
it in md (which must have space for SHA_DIGEST_LENGTH == 20 bytes of
output). If md is NULL, the digest is placed in a static array.
The following functions may be used if the message is not completely
stored in memory:
SHA1_Init() initializes a SHA_CTX structure.
SHA1_Update() can be called repeatedly with chunks of the message to be
hashed (len bytes at data).
SHA1_Final() places the message digest in md, which must have space for
SHA_DIGEST_LENGTH == 20 bytes of output, and erases the SHA_CTX.
Applications should use the higher level functions EVP_DigestInit(3)
etc. instead of calling the hash functions directly.
The predecessor of SHA-1, SHA, is also implemented, but it should be
used only when backward compatibility is required.
SHA1() returns a pointer to the hash value.
SHA1_Init(), SHA1_Update() and SHA1_Final() do not return values.
SHA: US Federal Information Processing Standard FIPS PUB 180 (Secure
Hash Standard), SHA-1: US Federal Information Processing Standard FIPS
PUB 180-1 (Secure Hash Standard), ANSI X9.30
closelog, openlog, syslog – send messages to the system
void openlog( char *ident, int option, int facility)
void syslog( int priority, char *format, …)
void closelog( void )
closelog() closes the descriptor being used to write to
the system logger. The use of closelog() is optional.
openlog() opens a connection to the system logger for a
program. The string pointed to by ident is added to each
message, and is typically set to the program name. Values
for option and facility are given in the next section.
The use of openlog() is optional; It will automatically be
called by syslog() if necessary, in which case ident will
default to NULL.
syslog() generates a log message, which will be dis-
tributed by syslogd(8). priority is a combination of the
facility and the level, values for which are given in the
next section. The remaining arguments are a format, as in
printf(3) and any arguments required by the format, except
that the two character %m will be replaced by the error
message string (strerror) corresponding to the present
value of errno.
This section lists the parameters used to set the values
of option, facility, and priority.
The option argument to openlog() is an OR of any of these:
write directly to system console if there is an
error while sending to system logger
open the connection immediately (normally, the con-
nection is opened when the first message is logged)
print to stderr as well
include PID with each message
The facility argument is used to specify what type of pro-
gram is logging the message. This lets the configuration
file specify that messages from different facilities will
be handled differently.
security/authorization messages (DEPRECATED Use
security/authorization messages (private)
clock daemon (cron and at)
other system daemons
LOG_LOCAL0 through LOG_LOCAL7
reserved for local use
line printer subsystem
USENET news subsystem
messages generated internally by syslogd
generic user-level messages
This determines the importance of the message. The levels
are, in order of decreasing importance:
system is unusable
action must be taken immediately
normal, but significant, condition
A syslog function call appeared in BSD 4.2.
logger(1), syslog(5), syslogd(8)
This command line tool is included with all versions of Mac OS X, and is also available on many other Unix platforms. To get started, try the following command.
sudo tcpdump -i en0 -s 0 -w DumpFile.dmp
Each element of the command line is explained below.
The sudo command causes tcpdump to run with privileges, which is necessary to access promiscuous mode.
The -i en0 option tells tcpdump to capture packets on the first Ethernet interface. You need to select an interface; there is no default. For a list of interfaces, type ifconfig -a. Mac OS X 10.1 and later provide packet capture support on PPP, so you can also specify a PPP interface here (for example, -i ppp0).
Note: If you need to capture PPP packets on traditional Mac OS, try using Interarchy or Sample Code Project ‘OTStreamDumper’.
The -s 0 option requests the full packet rather than just the first 68 bytes.
The -w DumpFile.dmp parameter tells tcpdump to dump the packets to a file called DumpFile.dmp.
In response to this command, tcpdump will begin to capture packets and put them in the DumpFile.dmp file. When you want to stop capturing, interrupt tcpdump by typing ^C. You can then display the contents of the packets as text using the following command.
tcpdump -s 0 -n -e -x -vvv -r DumpFile.dmp
New elements of the command line are explained below.
The -n option means that addresses are not converted to domain names, which speeds things up considerably.
The -e option causes tcpdump to display the link-level header for each packet.
The -x option causes the contents of the packet to also be displayed in hex.
The -vvv option makes tcpdump’s output as verbose as possible.
By specifying -r DumpFile.dmp option you tell tcpdump to read packets from the file DumpFile.dmp rather than from a network interface. Note that you don’t need privileges to do this, so running tcpdump using sudo is not required.
You can also combine these steps, as shown below, but if you do this you don’t get a high-fidelity record of the packets that you captured.
sudo tcpdump -i en0 -s 0 -n -e -x -vvv
You can learn about tcpdump from the online manual and from the book TCP/IP Illustrated, Volume 1, The Protocols, W Richard Stevens, Addison-Wesley, 1994, ISBN 0-201-63346-9. That book is also an excellent introduction to TCP/IP protocols in general.
Note: Mention of third party sites and third party products is for informational purposes only and constitutes neither an endorsement nor a recommendation. Apple assumes no responsibility with regard to the selection, performance, or use of these vendors or products.
Some of these tools have problems with packets being transferred to or from the trace machine (the machine running the tool). In general I recommend that your trace machine be separate from the machines whose network traffic you’re tracing. If you don’t follow this advice, please note the following anomalies.
EtherPeek on traditional Mac OS is unable to see packets being sent by the trace machine.
On Mac OS X, both EtherPeek and tcpdump will display bad IP checksums for packets being sent by the trace machine.
You should consult the documentation that comes with your tool for accurate and up-to-date information about its limitations.
If you use a separate trace machine, make sure that you connect all of the machines via a passive hub rather than a switch. Virtually all 10/100 hubs are actually switches, so you’ll probably have to dig through your boxes of old stuff for a 10 Mbit/s-only passive hub (or specifically look for a 10/100 hub that only switches between the different speed segments, for example the SMC-EZ58xxDS range).
If you send a packet trace to DTS, please include the following:
The name and version of the tool you used to capture the packet trace.
The system type and OS version of the trace machine.
If you’ve used either EtherPeek or tcpdump to capture your packet trace, you can send us the packet trace file in its native format. Otherwise, please include a copy of the packet trace in both its native format and, if that native format isn’t text, a text export of the trace as well. That way we’re guaranteed to be able to read your packet trace.
For each relevant machine shown in the trace, please describe the following:
The machine’s role in the network conversation.
The system type and OS version.
The machine’s IP address.
The machine’s hardware address (also known as the Ethernet address or MAC address).