Ever wonder what all those system processes are doing? So did I...
I
recently picked up Little Snitch and I've had a fun time watching all
the traffic that one little MacBook can send! I wasn't satisfied to just
filter my user-level programs -- why should I trust a system process
when it could be hijacked just like any user process? (For example, see this mDNSResponder vulnerability from June of this year that allows for arbitrary code execution. Yikes!)
So,
I decided I would actually bother to investigate what all those
different system-owned processes and daemons did. I've had some
adventures selectively enabling and disabling services with launchctl,
running processes through dtruss, Wireshark, and other tracing tools,
and occasionally breaking my computer along the way.
Here's what I've found on some of the processes you might have noticed if you ever disabled the protected rules:
AirPlayXPCHelper - Background on XPCs: An XPC
is user-level service (like a daemon) that runs in the background and
helps apps accomplish some goal. Apple recommends using XPCs for
fault-tolerance: if you have some component in your application that is
likely to crash, throw it in an XPC so that even if it crashes, the main
user-facing program won't, and can simply restart the XPC service. (Aside:
this seems like Apple is saying "got buggy code? Don't fix it, just
throw it in an XPC!" which sounds pretty awful but whatever, that's not
what we're here for). Furthermore, every individual XPC service is sandboxed so it can't affect other processes.
AirPlayXPCHelper
obviously helps with AirPlay. However, my AirPlayXPCHelper tried to
connect to something on port 7000. Since port 7000 isn't listed as an
AirPlay port on Apple's list of ports used by Apple products, I blocked it. Haven't had any issues so far.
AppleIDAuthAgent
- As the note on the protected rule states, "AppleIDAuthAgent is used
to check whether Apple-ID certificates are valid." I recommend letting
this one connect to Apple (and Apple only) at least periodically to keep
the system happy. I've blocked it at times, and the OS seems to accept
not being able to verify the user's identity sometimes.
apsd
- From the protected rule notes: "Part of Apple’s PushService
framework." Turn it on when you want push notifications from Apple,
block it otherwise. Note that apsd is responsible for sending and
receiving iMessages and texts in Messages, so if you use that then
you'll want to allow it access to the push.apple.com domain.
assistantd
- This is Siri, and other voice control stuff. I blocked it
unconditionally since I don't use the feature, and I'd rather my MacBook
not be always listening to everything. You can use launchctl to disable
the service permanently if you want; you can find it at
/System/Library/LaunchAgents/com.apple.assistantd.plist.
automount
- This tool mounts drives of all kinds, including network drives. If
you don't need to mount network drives, you're good to block this one.
(But don't disable it in your OS! Otherwise all kinds of stuff may not
mount properly)
cloudd - A
daemon related to iCloud. I allowed it to connect specifically to
iCloud servers while on my home network, and blocked it elsewhere.
Depends how accessible you need your iCloud to be. (Never use iCloud?
block away!)
com.apple.geod.xpc
- Another XPC, this one's name can be read "Geo-D", short for
"geolocation daemon". If you're paranoid about being tracked by The Man,
block this one unconditionally. I let it connect to Apple, because I
suspect it's used by Find My Mac, and I'm more worried about my laptop
being stolen than my location being tracked by the fed.
configd
- This one controls a host of mostly network-related tasks, but also
some other stuff. Use "man configd" in the terminal to take a look at
its manual. If you block it, you won't be able to connect to WiFi
hotspots, or at least not always or very well. So we have to allow some
traffic, but we can restrict it pretty hard: on most networks, it's
sufficient to only allow incoming UDP on ports 67 and 68, and outgoing
UDP on the local network.
findmydeviced
- As with com.apple.geod.xpc, this one comes down to whether you'd
prefer to find your stolen property, or not let Apple and other APTs
know your location.
gamed -
This is the daemon for the Games Center. If you never use the Games
Center (I don't), then you can not only block this one, but also disable
it using launchctl. When blocked, it retries every second, which can be
annoying, so disabling it is a nice fix.
helpd
- This daemon fetches content provided through the "Help" drop-down
menu of most applications. It will try to connect mostly to Apple, but
also occasionally to help resources on other domains (e.g. SourceForge)
for non-Apple applications. If you never use "Help", you can probably
block this one entirely. I let it connect to Apple and no-one else.
ksfetch - This is an updater daemon for Google products, notably Chrome. There's also a Google Software Update
app installed within Google Chrome.app, so I'm not sure why Google
needs an updater app AND an updater daemon. I have it blocked currently,
but maybe I shouldn't.
launchd
- This is a service dispatcher (like inetd on Linux) that launches
other services. It is sufficient to only allow incoming connections;
launchd just listens and launches other daemons to hand off the incoming
data to. I don't recommend turning it entirely off, since it will break
some stuff, but (in my experience) you can limit it to the local
network without issue, unless you're running a webserver or something.
mDNSResponder
- This one's been a big headache for me. It originally only did Bonjour
(Apple's "zeroconf networking" solution, allowing devices to find each
other automatically on the local network), but as of MacOS 10.6 it took
on a bunch of regular DNS tasks as well. I discovered this when I
disabled it entirely and found that it broke a bunch of stuff. I'm still
working on a good profile for it, but for now I have it very
selectively filtered: it can access a few DNS servers I trust on port 53
(DNS), and port 5353 (the Bonjour/mDNS port) only on my local network.
It's otherwise blocked off, and this seems to work alright for now. Your
mileage may vary. If you have a decent filter for mDNSResponder, I'd
love to hear about it.
mount_nfs and mount_url
- Just like automount, if you don't have any network drives to access,
you can safely block these entirely. Note that these two can mount
internet filesystems in addition to local ones.
netbiosd
- NetBIOS is a super-old local network drive-sharing protocol. If you
don't have any network drives on your local network to access, you can
block this one too.
nsurlsessiond
- I'm guessing that the "ns" at the beginning of this one's name refers
to "NeXtStep" and not "namespace", which indicates to me that this is
probably pretty old tech. I don't know all the things it's used for, but
it is used at least to sync data from iCloud. Others are finding it's
also responsible for leaking your data to Apple and Microsoft
in the built-in Spotlight and Bing searches (if you haven't already,
turn off Spotlight Suggestions and Bing Search from the Spotlight
settings so that your keystrokes aren't all sent over the wire whenever
you search for a local file). I've got it locked down to only call out
to iCloud servers, and that seems to work well.
ntpd and sntp
- These little daemons keep your system clock in sync with Apple's
clocks. I'm not sure why the OS needs two of them (looking into this is
on my to-do list). Blocking them does little harm, but I suggest instead
just locking them down to only be able to connect to Apple's servers.
ocspd
- This daemon is used by the system to check X.509 certs. I've got it
blocked when I'm outside of my own home for now, and that doesn't seem
to be a problem. I assume it might be a problem if I try to install any
new software while it's blocked.
storeaccountd and storeassetd
- So far I've only ever seen these two call out to iTunes-related
domains. I assume they do "what it says on the tin," grabbing resources
for the Store. I've got them blocked everywhere, and I disable the rule
when I need to use the Apple Store or iTunes Store. Streaming music in
iTunes through Apple Music doesn't seem to be affected by them being
blocked, so I'm guessing it's only for actual Store stuff.
syncdefaultsd
- Yet another iCloud-related thing, this guy keeps various preferences
sync'd between Apple devices and such. You can probably block it, at
least outside of your home network.
trustd
- Like ocspd, this one verifies certificates. I haven't seen much
traffic from it, and I have it blocked everywhere that isn't my own
home, which seems to work fine.
---
I hope this information is helpful to someone out there. Stay safe, and good luck setting up your own profiles!