DON’T LOG TO THE SD CARD!!!

This keeps coming up, so let me shout it from the mountain top for all the internets to hear:

“DON’T EVER EVER EVER LOG TO THE SD CARD!”

Selinux policy often contains evidence that a process can or may store logs on external storage. I commonly see groups of permissions that look something like:

allow foo fuse:dir { write search read create open add_name };

allow foo fuse:file { read write create open };

allow foo mnt_user_file:dir search;

allow foo mnt_user_file:lnk_file read;

allow foo storage_file:dir search;

allow foo storage_file:lnk_file read;

Why is logging to the sdcard dangerous?

1. Logs contain very sensitive information e.g. websites or IP addresses visited, application data, personal data, passwords, auth tokens, memory dumps, stack dumps, register values, etc.
2. The sdcard is not encrypted.
3. The sdcard is not wiped on factory reset.
4. Applications have access to the sdcard, meaning they can read (and potentially exfiltrate) any logs on the sdcard.

Logging to the sdcard is bad for users for the reasons above, but it’s not just user data at risk. When companies log to the sdcard (e.g. during platform development) their data is at risk. Third party applications may access or exfiltrate logs and all the sensitive data contained. This should be extremely concerning to device manufacturers.

Here are some safe guidelines when it comes to logging.

1. Logs should never be persisted to disk on production (user) builds.
2. On debug/eng builds, persisted logs should be encrypted on the data partition
3. Only persist logs using logcat’s built in logpersist APIs.
4. Device specific daemons and processes should only log to Android’s built in system log. Android’s built in logging mechanisms have been extensively reviewed and have safe defaults. Using these built in logging capabilities means that you will be safe by default.

Let me know if you have any questions.