Stephen Smalley wrote:
On 09/10/2013 09:25 AM, Joshua Brindle wrote:
You didn't include my two changes. Was that because you didn't agree
with them or you just wanted to keep them separate?
I don't normally pull peoples patches into my own :) I can do that if
you want.
As my changes are essentially bug fixes (one for your code, one for
Bill's), I'm fine with folding them, and they are public domain so that
isn't a problem.
Okay, I rolled them in.
I'd rather it work the same way upstream auditd works.
Ok. I actually retried the -e 1 approach and it still seems to run up
against EAGAIN errors so I'm not clear on what is happening there. So
directly calling audit_set_enabled() as in my patch seems the better route.
I also seem to get errors if I try to include more than one watch rule,
I/auditd ( 119): Starting up
I/audit_log( 119): Previous audit logfile detected, rotating
E/audit_rules( 119): -w /data/system -p wa
E/audit_rules( 119): -w /data/security -p wa
E/audit_rules( 119): Unknown permission
I'm guessing that is a bug in your parser?
Strange. I've been testing with multiple rules all along:
I do get strangeness with the sequence numbers though:
I/auditd ( 1682): Starting up
I/audit_log( 1682): Previous audit logfile detected, rotating
W/libaudit( 1682): Expected sequence number between user space and
kernel space is out of skew, expected 2 got 0
E/audit_rules( 1682): -w /system -pw
W/libaudit( 1682): Expected sequence number between user space and
kernel space is out of skew, expected 3 got 0
E/audit_rules( 1682): -w /data/secuity -pw
W/libaudit( 1682): Expected sequence number between user space and
kernel space is out of skew, expected 4 got 0
E/audit_rules( 1682): -w /dev/block -pwra
W/libaudit( 1682): Expected sequence number between user space and
kernel space is out of skew, expected 5 got 0
E/audit_rules( 1682): #-e 2
Yes, but it looks like the auditd gerrit review has been rejected.
Should I submit anyway?
Not rejected (not a CR-2) but just doesn't verify against Google
internal tree. That's ok; it just means that they have to resolve it
internally.
Once you resolve the above error/bug, I'd suggest that you go ahead and
upload it as a new change relative to Bill's change.
I uploaded but will try to figure out what is going on and update.
Can you attach your audit.rules?
I also originally had audit.rules in /data/security but one of my phones
has that set to 0700 owned by system so auditd couldn't read it. I'd
rather it be there (and possibly included in the bundles we are talking
about elsewhere).
On AOSP master and on our seandroid* branches, /data/security is 0711.
But it shipped in android-4.3_r1 as 0700.
Not sure yet about whether we can/should add more files there or to the
SELinuxPolicyInstallReceiver. We could always have a separate
ConfigUpdateInstallReceiver instance that handles audit.rules and drops
them to /data/misc/audit. They have similar receivers for
/data/misc/keychain, /data/misc/sms, and /data/misc/zoneinfo (see
frameworks/base/services/java/com/android/server/updates). Only reason
to make it part of the SE bundle is if we expect it to become coupled,
e.g. audit rules written in terms of SELinux contexts, which I suppose
is possible.
Sounds good..
--
This message was distributed to subscribers of the seandroid-list mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe seandroid-list" without quotes as the message.
