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

Robert Watson rwatson at FreeBSD.org
Mon Nov 7 14:59:57 GMT 2005


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.
>>
>
To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-audit" in the body of the message



More information about the trustedbsd-audit mailing list