Re: [PATCH] IPC_SET_PERM cleanup
On Tue, May 09, 2006 at 01:47:26PM -0400, Linda Knippers wrote:
I'm starting to wonder whether we actually need the
IPC_NEW_PERMS
record. We don't spell out similar information for chown, for
example. In that case, the new owner is a1 field. Do we treat IPC's
differently because their argument is a structure pointer?
Yes, that's the difference. chown takes an integer argument that's
already contained in the syscall record, even though "a1" isn't a very
descriptive name for it. For ipc_set, the argument is the address of the
structure which would be useless, and the extra record makes the content
of the structure available.
In any case, if someone truly wanted to get all audit records that
had the uid either as part of the subject/object identity and also
included all records that had the uid as an argument, they'd need
to look at the a* fields for other system calls as well. Since we
don't look at the a* arguments for other syscalls, it doesn't seem
like we should include the arguments for the IPC syscalls if someone
is searching for the records generated by a uid.
CAPP requires audit records for "All modifications of the values of
security attributes" for 5.4.1 Management of Object Security Attributes
(FMT_MSA.1). It doesn't specifically require the new values as detail
information for the audit record, so if you just want to meet the letter
of CAPP you could leave it out, but the record is of course far more
useful if you include the information.
How the search on UID works in detail isn't all that important. I think
the main issue is that the syscall record contains correct and useful
information. For chown, someone who cares about the argument UID can look
at the "a1" field, but I don't think it would be necessary to have an
easy search method available for that.
If you want something equivalent for ipc_set, having fields with
unsearchable names would be fine, which happens to be what you
get with the "new_iuid" style field names.
-Klaus