We currently use both audit messages from auditd log and logcat messages. We found it very useful to have both. The auditd log allows us to quickly check if there is any unexpected audit messages. Audit messages in logcat give us the context of the error.
Tai From: William Roberts <[email protected]<mailto:[email protected]>> Date: Thursday, June 19, 2014 at 9:16 AM To: Stephen Smalley <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Ruowen Wang <[email protected]<mailto:[email protected]>> Subject: Re: No auditd in seandroid-4.4.3. Is there a way to add it back? That works fine in a development scenario, for deployed devices just filter on logcat with an app and save to disk or offload. The drawback there is that you have to filter a stream at one point that was isolated from the stuff you didn't care about, thus wasting battery for nothing. As we have all seen, logcat is quite chatty. The other option is to hack logd to send to logcat and a separate stream, perhaps to disk or wherever you would like. On Jun 19, 2014 5:27 AM, "Stephen Smalley" <[email protected]<mailto:[email protected]>> wrote: On 06/18/2014 02:58 PM, Ruowen Wang wrote: > Hi all, > > Looks like the auditd daemon has been removed in seandroid-4.4.3 branch. > Is it because of some security issues of the auditd? Because we have a > large number of denials to analyze, we previously increased the size of > audit.log. I don't know if there is a way to add auditd back, or some > other ways maybe increase the buffer size of dmesg? I dropped it because AOSP master has integrated audit support into logd (avc messages now available in logcat output there) and therefore auditd has no long term future as a separate service. adb shell su 0 cat /proc/kmsg > dmesg.txt & is what we commonly use to collect denials on 4.4.3 and earlier. Then you don't have to worry about rollover of the kernel ring buffer as they will all be saved to a file on the host. Or if you want to capture them all across multiple reboots (as during a CTS run), you can do something like this: while (true) do adb shell su 0 cat /proc/kmsg >> dmesg.txt adb wait-for-device done _______________________________________________ Seandroid-list mailing list [email protected]<mailto:[email protected]> To unsubscribe, send email to [email protected]<mailto:[email protected]>. To get help, send an email containing "help" to [email protected]<mailto:[email protected]>.
_______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
