netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: Linux Audit Discussion <linux-audit@redhat.com>
Cc: kuznet@ms2.inr.ac.ru, davem@davemloft.net, netdev@oss.sgi.com
Subject: Re: [PATCH] Add audit uid to netlink credentials
Date: Thu, 10 Feb 2005 10:10:23 -0800 (PST)	[thread overview]
Message-ID: <20050210181023.92819.qmail@web50202.mail.yahoo.com> (raw)
In-Reply-To: <20050210175221.GA13458@w-m-p.com>


--- Klaus Weidner <klaus@atsec.com> wrote:

> Both CAPP and LSPP assume trustworthy
> administrators, and those
> protection profiles don't really support the concept
> of fine grained
> capabilities for not-quite-administrator tasks.

I don't know where you get that idea, as it is
inconsistent with the evaluations I have done.
A fine grained capability model that is used
will always make an evaluation easier. A process
that runs with partial privilege requires much
less supporting evidence for evaluation than
one that has superuser privilege. The Criteria
may not require fine grained privilege, but
that does not mean it doesn't help.

> The CAPP and LSPP audit requirements include that
> audit records contain
> the subject identity, this corresponds to the login
> UID.

The subject identity is the name of the subject,
that is the process ID. The user associated with
the session is the login UID. The user is not the
subject.

> The point of the
> user messages is to support proper auditing of
> actions that aren't
> directly related to system calls, such as
> authenticating users, modifying
> security databases, and similar things. This is
> always done by trusted
> processes, so the technical method used to get the
> login UID into the
> audit record for user messages doesn't matter as
> long as it can't be
> falsified by non-administrators.

This is correct as far as it goes. One of the
requirements is to correctly audit attempts made
by unprivileged users to write to the audit trail.
This is one reason you need the login UID of the
process attempting to write to the audit trail.

> A CAPP/LSPP compliant implementation could for
> example completely bypass
> the kernel and append user messages from trusted
> processes directly to
> the audit log file - I'm not saying that would be a
> good idea, but it
> could be compliant.

It is actually a very good idea to maintain
modifications to system security databases outside
the audit trail proper. In the Orange Book days
the NSA went so far as to declare a that a
reasonable procedure for keeping them under
revision control would be sufficient to meet the
audit requirements.

Another mechanism that would work well is to
send the user space records directly to the
audit daemon using a protected socket.


=====
Casey Schaufler
casey@schaufler-ca.com


	
		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - You care about security. So do we. 
http://promotions.yahoo.com/new_mail

  reply	other threads:[~2005-02-10 18:10 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-10 14:37 [PATCH] Add audit uid to netlink credentials Chad Hanson
2005-02-10 14:56 ` David Woodhouse
2005-02-10 17:52   ` Klaus Weidner
2005-02-10 18:10     ` Casey Schaufler [this message]
2005-02-10 19:26       ` Klaus Weidner
  -- strict thread matches above, loose matches on Subject: below --
2005-02-10 15:16 Chad Hanson
2005-02-04 16:58 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
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

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=20050210181023.92819.qmail@web50202.mail.yahoo.com \
    --to=casey@schaufler-ca.com \
    --cc=davem@davemloft.net \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-audit@redhat.com \
    --cc=netdev@oss.sgi.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;
as well as URLs for NNTP newsgroup(s).