some questions about audit

[xuejian03 at ios.cn]

Thank you very much for patient explanations, they are really helping. 

 

The following is what my mentor and I would do in the next few months: 

(1) Add object’s security level to the audit trail 

(2) Add the event of overriding of human readable output markings 

(3) Try to provide more choices when the audit trail overflow happens. At 
present there are only two policies available: drop records, or panic. Maybe 
rotating to the oldest file could be another choice. 

(4) We want to add a command to dynamically adjust the state of auditing 
while a user's process are active, as audit_config does on solaris with the 
 -setpmask options. 

 

We also hope to do something else after the above (1)(2)(3)(4) are done. 
It's our great honor if we could do some help for the kernel or the 
applications, such as sweeping out the system calls or user-space programs. 

 

Besides, after analyzing the code carefully, I have some more detailed 
questions 

(a)The AUE_WAIT4 event is not correctly dealt with in the kaudit_to_bsm() 
function. So the unfriendly warning "BSM conversion requested for unknown 
event 370" jumps every now and then. Maybe it's a bug? 

(b) Why is the terminal ID always 0? Can we assign something more 
meaningful? 

(c) The A_SETPOLICY cmd of auditon system call sets audit policy flags. 
Currently, only AUDIT_CNT and AUDIT_AHLT are implemented. But why they can 
occur at the same time? Maybe it’s confusable. 

(d) The ai_mask of child process is copied from parent without any 
modification. So, if a user login while auditing is disabled, then none of 
his action would be recorded, even after auditing is enabled. I think it’s 
necessary to do some checking in function audit_proc_fork(). If the auditing 
condition has been changed, then the children’s mask will be recomputed. 

(e) Some global variables are not be initiated in audit_init(), such as 
audit_in_failure, audit_fail_stop, audit_panic_on_write_fail. 

 

Thanks to all in advance. 

Robert Watson writes: 

> 
> On Wed, 12 Oct 2005, panxj wrote: 
> 
>> 	I have downloaded trustedbsd_audit3 through perforce, and wanna to add 
>> some further enhancement to it. I'm reading the soure code, but now have 
>> some questions: 
>> 
>> (1)There are over 1000 system-calls in current system(including the 
>> bianry-compatible system-calls, such as functions listed in 
>> linux_sysent). But arguments-collection points are only added in about 28 
>> funcitons. Is it sufficient? And is there any documents about why these 
>> collection points are added?
> 
> The answer varies a bit by system call and system component, but the 
> status goes something like this: 
> 
> While there are many ABI's available that implement literally thousands of 
> system calls, the vast majority of those system calls are identical to a 
> relatively small set of base calls.  For example, while there are minor 
> syntactic differences between sendfile() in the 32-bit system call ABI for 
> FreeBSD and the 64-bit one, they are basically the same system call.  As 
> such, they will be audited as the same event, AUE_SENDFILE.  Likewise, you 
> will find literally dozens of various on stat() across Linux emulation, 
> this emulation, old versions of stat() with smaller sizes, etc.  These 
> will all be emulated as AUE_STAT. 
> 
> What's particularly helpful is that not only are the events basically 
> identical, but they are also implemented by the same code in most cases: 
> the emulation layer is simply a wrapper that converts, say, native Linux 
> layout for a structure into the FreeBSD version of the structure, and then 
> converts in the reverse direction on return. 
> 
> For example, linux_fstat64() is implemented as a small wrapper around 
> kern_fstat(), which is the internal kernel implementation of the fstat() 
> system call.  This means that augument auditing in that one spot, 
> kern_fstat(), will capture the necessary information about all fstat() 
> variations.  This does discard some potentially interesting information: 
> that the call was made via the Linux ABI; however, it was concluded that 
> the improved cleanliness and centralization of the audit implementation 
> outweighed the benefit of providing this additional information.  It may 
> make sense to add an additional token to the AUE_EXECVE audit record to 
> capture what ABI is used for the binary, however. 
> 
> Likewise, path information is uniformly collected in namei(), with the 
> caller indicating which string is to be audited (the first or second). 
> 
> There are a few system calls in emulation layers, such as Linux's getcwd() 
> system call, and library mapping functions, that will need additional 
> work. 
> 
>> (2)What's the status of the audit-subsystem? If it has been done for 90%, 
>> or 30%? When it will be added to the release? Thanks to all in advance.
> 
> However, it is still the case that a number of arguments are inadequately 
> audited.  We are constructing a table of system calls and arguments in the 
> audit3 tree, under the notes sub-directory.  It's currently not very 
> complete, but we're working on fleshing it out.  Recent work (in the past 
> few weeks) has focused on cleaning up the event framework itself, and 
> doing some necessary restructuring.  We've also been adapting to recent 
> changes to an MPSAFE VFS in the base FreeBSD tree (now done), and been 
> adding BSM event identifiers for system calls present in FreeBSD and 
> emulated platforms that are not present in Solaris (such as sendfile()). 
> 
> Originally the plan was to integrate the audit support, including the 
> OpenBSM libraries and components, into FreeBSD for the 6.0 release. 
> However, as we're waiting on Apple to re-release a couple of the audit 
> source files under the BSD license instead of APSL, that was deferred. The 
> original hope was that the relicensing would be done in June, which 
> obviously hasn't happened.  It is apparently moving through Apple Legal 
> and we hope for progress soon.  As such, my current target is FreeBSD 6.1 
> as an experimental feature. We'll begin merging parts to 7.x as soon as 
> the license is fixed. 
> 
> In terms of overall completeness -- Wayne Salamon and I have been starting 
> to assemble a todo list on what remains, which can be found in Perforce: 
> 
>    //depot/projects/trustedbsd/audit3/notes/TODO_audit.txt 
> 
> This is also in the cvsup export.  In particular, we need to complete a 
> sweep of all system calls and arguments to make sure they are audited. In 
> the case of new record types we've added for BSD system calls, we need to 
> more formally define the structure of the record in terms of expected 
> tokens.  We also need to take a sweep through user space, which currently 
> has not had a lot of attention paid to it, and requires that attention. 
> Another task of importance is integrating the audit mechanism with the MAC 
> Framework so that MAC security policies can annotate audit records.  Wayne 
> has a first cut of this as part of work he has done for SPARTA, and some 
> of which is now available via the DSEP Darwin tree from our port to 
> Apple's Darwin platform.  Finally, a lot of testing, and expecially 
> testing tools, is required. 
> 
> If you'd like to lend a hand with any of these things, especially 
> unclaimed items in the todo list, would be great.  One of the things that 
> doesn't have an owner and would make a good chunk to work on is teaching 
> our praudit implementation how to convert binary BSM log files into the 
> XML output format Sun has now defined, as this may be more appropriate for 
> analysis by higher level applications.  This should also help expose 
> things missing in our audit trail. :-) 
> 
> Thanks, 
> 
> Robert N M Watson
 
To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message