<div>Thanks for your answer :-)<br> </div>
<div>Are there some other operating systems or other docs that can be helpful to select syscalls to be audited?</div>
<div><br> </div>
<div><span class="gmail_quote">On 11/7/05, <b class="gmail_sendername">Robert Watson</b> <<a href="mailto:rwatson@freebsd.org">rwatson@freebsd.org</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br>On Mon, 7 Nov 2005, Yuan MailList wrote:<br><br>> Thanks for your answer.<br>><br>> When selecting the audit syscall, are there some criterias?
<br>><br>> It means that why some syscalls are audited but others are not audited.<br><br>There are really two sets of criteria:<br><br>- Those laid out in the common criteria requirements for CAPP (and soon,<br> LSPP).
<br><br>- More calls that also seem interesting and security-relevant.<br><br>The former covers a pretty large scope, since CAPP requires audit of<br>pretty much everything involved in access control, which is quite frequent
<br>for system calls. The latter tends to be things not strictly required by<br>CAPP, but still useful. Pipes are one example of this -- they're an<br>important system IPC object, but because they are capability oriented
<br>(i.e., they are passed around, and if you get a reference, you can use<br>it), rather than involving explicit access control, they aren't audited in<br>most CAPP-evaluated systems. I can't remember if we covered it in Mac OS
<br>X or not.<br><br>More objects are likely required to be audited when running with MAC, as<br>there are more points for explicit access control. I.e., while UNIX DAC<br>doesn't care about access control for read() and write() in most cases
<br>when operating on files or simple IPC objects, MAC will care.<br><br>Robert N M Watson<br><br>><br>><br>> On 11/7/05, Ilmar S. Habibulin <<a href="mailto:ilmar@watson.org">ilmar@watson.org</a>> wrote:<br>
>><br>>><br>>><br>>> On Fri, 4 Nov 2005, Yuan MailList wrote:<br>>><br>>>> 2. Why not audit syscall write(2)/writev/dup2 in trusted_audit3?<br>>>> I think these syscalls are important for system security and should be
<br>>>> audited. For security, the events of write and modify to files are more<br>>>> important than those of read to files. Is it right? :-)<br>>><br>>> if you will simply audit write call, your trail will be trashed with such
<br>>> entries. you need just open for writing audit entry, nothing more in<br>>> common situation. the only one reason to audit write calls is MAC, or even<br>>> MAC debugging. Because labes of subjects and objects may change between
<br>>> two write calls to the same fd. So audit records wiil help to track down<br>>> the problem.<br>>><br>><br></blockquote></div><br>