All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Linux Audit Discussion <linux-audit@redhat.com>
Cc: Stephen Smalley <sds@epoch.ncsc.mil>,
	netdev@oss.sgi.com, davem@davemloft.net, kuznet@ms2.inr.ac.ru
Subject: Re: [PATCH] Add audit uid to netlink credentials
Date: Wed, 09 Feb 2005 23:56:09 +0000	[thread overview]
Message-ID: <1107993369.9154.2.camel@localhost.localdomain> (raw)
In-Reply-To: <20050209153816.B24171@build.pdx.osdl.net>

On Wed, 2005-02-09 at 15:38 -0800, Chris Wright wrote:
>> So you also think it should be in the payload?  That would require
>> security_netlink_send to dig into the payload if we wanted to control
>> who can specify other loginuids, as Serge noted.
>
>I just don't see it making sense to add another credential for a special
>case.  The signal code already peaks into the siginfo struct when queueing
>a signal to make sure some user isn't trying to send si_code == SI_KERNEL
>or similar.  Perhaps audit could do that with it's own payload during send.
>No matter how we slice it, it's a special case.

I'm not entirely sure the check is needed anyway. This is a trusted
application sending audit messages. Why shouldn't it be permitted to log
auditable events which were triggered by someone _else_? 

If we want to audit the actions of the userspace logging dæmon itself
and see what it sends, then we can quite happily do so within the audit
framework. That's a _different_ issue, surely?

-- 
dwmw2

  reply	other threads:[~2005-02-09 23:56 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-04 16:58 [PATCH] Add audit uid to netlink credentials Serge E. Hallyn
2005-02-08  6:04 ` Patrick McHardy
2005-02-09 13:34   ` Stephen Smalley
2005-02-09 14:10     ` Patrick McHardy
2005-02-09 14:19     ` Alexey Kuznetsov
2005-02-09 16:49       ` Alexey Kuznetsov
2005-02-09 18:52         ` Patrick McHardy
2005-02-09 18:53           ` Stephen Smalley
2005-02-09 14:17 ` David Woodhouse
2005-02-09 14:50   ` Serge Hallyn
2005-02-09 18:23     ` Stephen Smalley
2005-02-09 18:37       ` Chris Wright
2005-02-09 18:40         ` Stephen Smalley
2005-02-09 23:38           ` Chris Wright
2005-02-09 23:56             ` David Woodhouse [this message]
2005-02-10  0:19               ` Chris Wright
2005-02-10  9:20                 ` David Woodhouse
2005-02-10 12:40                 ` Stephen Smalley
2005-02-10 12:49                   ` David Woodhouse
2005-02-10 17:14                   ` Chris Wright
2005-02-10  1:11             ` Chris Wright
2005-02-10 12:36               ` Stephen Smalley
2005-02-10 12:51                 ` Stephen Smalley
  -- strict thread matches above, loose matches on Subject: below --
2005-02-10 14:37 Chad Hanson
2005-02-10 14:56 ` David Woodhouse
2005-02-10 17:52   ` Klaus Weidner
2005-02-10 18:10     ` Casey Schaufler
2005-02-10 19:26       ` Klaus Weidner
2005-02-10 15:16 Chad Hanson

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=1107993369.9154.2.camel@localhost.localdomain \
    --to=dwmw2@infradead.org \
    --cc=davem@davemloft.net \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-audit@redhat.com \
    --cc=netdev@oss.sgi.com \
    --cc=sds@epoch.ncsc.mil \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.