Linux-audit Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Klaus Weidner <klaus@atsec.com>
To: Linda Knippers <linda.knippers@hp.com>
Cc: linux-audit@redhat.com
Subject: Re: [PATCH] IPC_SET_PERM cleanup
Date: Tue, 9 May 2006 13:15:23 -0500	[thread overview]
Message-ID: <20060509181523.GD31457@w-m-p.com> (raw)
In-Reply-To: <4460D5AE.8040700@hp.com>

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

  reply	other threads:[~2006-05-09 18:15 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-05 20:19 [PATCH] IPC_SET_PERM cleanup Linda Knippers
2006-05-05 20:42 ` Steve Grubb
2006-05-05 20:59   ` Linda Knippers
2006-05-09 14:51     ` Klaus Weidner
2006-05-05 21:26 ` Linda Knippers
2006-05-08 18:29 ` Dustin Kirkland
2006-05-08 18:29 ` Dustin Kirkland
2006-05-08 19:06   ` Linda Knippers
2006-05-09 14:59   ` Klaus Weidner
2006-05-09 15:05     ` Steve Grubb
2006-05-09 15:12       ` Linda Knippers
2006-05-09 15:21         ` Steve Grubb
2006-05-09 15:34           ` Linda Knippers
2006-05-09 15:55             ` Steve Grubb
2006-05-09 16:33               ` Klaus Weidner
2006-05-09 17:47               ` Linda Knippers
2006-05-09 18:15                 ` Klaus Weidner [this message]
2006-05-09 18:27                   ` Linda Knippers
2006-05-09 19:11                     ` Steve Grubb
2006-05-09 20:10                       ` Klaus Weidner
2006-05-09 20:36                         ` Klaus Weidner
2006-05-09 20:46                           ` Linda Knippers
2006-05-10 14:02                             ` Steve Grubb
2006-05-10 16:29                               ` Klaus Weidner
2006-05-10 17:02                                 ` Dustin Kirkland
2006-05-10 17:11                                   ` Klaus Weidner
2006-05-10 17:22                                     ` Linda Knippers
2006-05-10 17:29                                     ` Steve Grubb
2006-05-10 18:10                                       ` Klaus Weidner
2006-05-10 17:28                                 ` Steve Grubb
2006-05-10 18:05                                   ` Linda Knippers
2006-05-10 18:20                                     ` Steve Grubb
2006-05-09 15:53           ` Amy Griffis
2006-05-09 15:07 ` Steve Grubb

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060509181523.GD31457@w-m-p.com \
    --to=klaus@atsec.com \
    --cc=linda.knippers@hp.com \
    --cc=linux-audit@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox