What is invalid class in openbsm? And why not audit write/writev/dup2?
yuan.maillist at gmail.com
Tue Nov 8 06:16:32 GMT 2005
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,
> - 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
> >>> important than those of read to files. Is it right? :-)
> >> if you will simply audit write call, your trail will be trashed with
> >> 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
> >> 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
> >> the problem.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the trustedbsd-audit