Andrew Storms
2006-Sep-20 08:24 UTC
Status of MFC security event audit support in RELENG_6?
A few weeks back Robert Watson announced the merge of these features from 7 back into 6-STABLE. I hadn't seen any updates and was curious as to the status. Us 6-STABLE users are curious to test it out. Thanks. --A
Bruce A. Mah
2006-Sep-20 09:03 UTC
Status of MFC security event audit support in RELENG_6?
If memory serves me right, Andrew Storms wrote:> A few weeks back Robert Watson announced the merge of these features from 7 > back into 6-STABLE. I hadn't seen any updates and was curious as to the > status. Us 6-STABLE users are curious to test it out.From the re@ perspective: It's still on track for shipping as a part of 6.2-RELEASE as an experimental feature. The audit developers have a few more MFCs planned before the release, but as of right now, I'm told that the audit feature is working in 6-STABLE. (I personally have not worked with this feature yet, so YMMV.) Cheers, Bruce. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20060920/cada2c7b/signature.pgp
Robert Watson
2006-Sep-21 00:55 UTC
Status of MFC security event audit support in RELENG_6?
On Wed, 20 Sep 2006, Andrew Storms wrote:> A few weeks back Robert Watson announced the merge of these features from 7 > back into 6-STABLE. I hadn't seen any updates and was curious as to the > status. Us 6-STABLE users are curious to test it out.The MFC is largely complete, and we're now basically chasing and address bugs being reported by -CURRENT and -STABLE users of audit. BETA1 ships with audit support, but there are a few known issues with it: - The sparc64 BETA1 ISO doesn't include the auditctl(2) bugfix, so auditd cannot be started. amd64 and i386 both do include this fix so auditd should start properly. - User applications are unable to submit audit records due to a bug in uer record audit preselection. The fix has been tested and merged to RELENG_6, but didn't make the BETA1 cutoff. BETA2 will include the fix, and it's available if you update to the latest RELENG_6 also. - There are both kernel and praudit bugs relating to extremely large audit records generated by turning on argv or envv auditing with execve(1). These bugs have been fixed in -CURRENT but the fixes are not yet merged to RELENG_6. They will be merged in the next few days once they've settled a bit in HEAD. However, as the version of OpenBSM in RELENG_6 doesn't currently allow turning on the argv and envv auditing flag, this doesn't present an immediate problem for audit users in RELENG_6. Support for turning on argv/arge auditing via audit_control(5) will appear in the OpenBSM 1.0 alpha 11 MFC to RELENG_6 in a few days (prior to BETA2). - There are some known usability issues when the audit store partition becomes very full. In particular, you get a lot of kernel printfs, which can slow the system down a lot and could make the console unusable. Fixes for this are on my notebook, and will be merged to P4 and CVS HEAD shortly, with an MFC planned before BETA2. Basically, these changes rate limit warning messages and are a bit more careful to avoid hitting out of space errors. Bug fixes to improve auditd's handling of low space conditions and triggers are in HEAD and will be MFC'd with OpenBSM 1.0 alpha 11. - 32-bit compatibility system calls on amd64 are not currently audited, as with emulated Linux system calls in RELENG_6. I'm working on the MFC patch for this currently, so hope to get the compat32 auditing merged in the next day or so (once approved by re@). Testing and feedback would be extremely welcome. While the above list of RELENG_6 problems is non-trivial, the code currently in RELENG_6 is quite functional, and I've deployed it on several servers, as have a number of other developers and end-users. Another thing that needs to happen before the release is that the Handbook chapter needs to be reviewed and updated. In particular, we've added the policy: line to audit_control(5) since it was written, and since this is quite useful/important, an update is required for that. Robert N M Watson Computer Laboratory University of Cambridge