Re: [PATCH] IPC_SET_PERM cleanup
Klaus Weidner wrote:
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.
I wasn't actually proposing that we do that. I was really trying to
make the point that including the iuid and new_iuid fields in with
the results of a uid search, which is what Steve was proposing as a
good thing, doesn't seem right to me. There are lots of other syscalls
that could have the uid as an argument that would be skipped so pulling
in the ipc ones just because the arguments are labeled seems
inconsistent and not useful.
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.
Maybe I should use a5, a6, ..., since they're really just more
arguments, although we'd probably have to document which values
we're including since there are more arguments that aren't
being recorded.
-Klaus