What is invalid class in openbsm? And why not audit write/writev/dup2?

[Yuan MailList]

Thanks for your answer :-)
 Are there some other operating systems or other docs that can be helpful to
select syscalls to be audited?

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