8:37 a.m.
David Woodhouse wrote:
On Wed, 2005-02-09 at 16:19 -0800, Chris Wright wrote:
> Then it comes back to the question of how to protect loginuid. If it
> can be spoofed by someone with CAP_AUDIT_WRITE, then it shouldn't be
> write protected by CAP_AUDIT_CONTROL.
I'm not sure I agree with that. With CAP_AUDIT_WRITE you _can't_ modify
the loginuid of the audit logs of your own actions. You can only modify
the loginuid on the messages you pull out of thin air and send. You can
already make up the rest of the payload -- why shouldn't you be allowed
to make up the loginuid too? You could be reporting something that
someone _else_ has done, after all.
I'm not sure I understand this logic.
Let me start with some background. The purpose of the loginuid is to record
the original creator of the process regardless of credential changes since
login. We use a capability to protect this, so it cannot be altered by most
programs, even those which write audit records. Placing the loginuid in the
payload effectively removes the purpose of CAP_AUDIT_CONTROL from all
userland audit messages. A program may be privileged to write an audit
record, but a granular security approach would not let them have the ability
to change the loginuid as well.
In your example of a process watching daemon, why would this daemon want to
spoof the credentials of the watched process? I can think of two examples.
One you are recording information for IDS like purposes of system and
process state. This could be a good use of audit, however, I don't
understand the need to make the loginuid of the audit logs match the process
you are watching. If you really did, y0ou are a heavily privileged process
already to watch all of these other processes, simply change your loginuid
through CAP_AUDIT_CONTROL and add that to the other privileges you already
have in monitoring the system state.
-Chad
8:56 a.m.
New subject: [PATCH] Add audit uid to netlink credentials
On Thu, 2005-02-10 at 09:37 -0500, Chad Hanson wrote:
In your example of a process watching daemon, why would this daemon
want to
spoof the credentials of the watched process? I can think of two examples.
Perhaps I misunderstand the intent of userspace AUDIT_WRITE. Can you
provide examples of why you _wouldn't_ want to let a dæmon which is
already sending random unvetted AUDIT_WRITE messages also specify the
loginuid on _those_ messages?
--
dwmw2
11:52 a.m.
New subject: [PATCH] Add audit uid to netlink credentials
On Thu, Feb 10, 2005 at 02:56:36PM +0000, David Woodhouse wrote:
On Thu, 2005-02-10 at 09:37 -0500, Chad Hanson wrote:
> In your example of a process watching daemon, why would this daemon want to
> spoof the credentials of the watched process? I can think of two examples.
Perhaps I misunderstand the intent of userspace AUDIT_WRITE. Can you
provide examples of why you _wouldn't_ want to let a dæmon which is
already sending random unvetted AUDIT_WRITE messages also specify the
loginuid on _those_ messages?
A few comments on this issue from the point of view of common criteria
evaluations... Briefly, either choice of implementation would be okay.
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.
The CAPP and LSPP audit requirements include that audit records contain
the subject identity, this corresponds to the login UID. 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.
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.
-Klaus
12:10 p.m.
New subject: [PATCH] Add audit uid to netlink credentials
--- Klaus Weidner <klaus(a)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(a)schaufler-ca.com
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail
1:26 p.m.
New subject: [PATCH] Add audit uid to netlink credentials
On Thu, Feb 10, 2005 at 10:10:23AM -0800, Casey Schaufler wrote:
--- Klaus Weidner <klaus(a)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.
My point was that the security functional requirements in CAPP and LSPP
related to audit and user management only differentiate between
authorized users and authorized administrators, and adding a finer
grained distinction to those SFRs would be incompatible with CAPP/LSPP.
CAPP and LSPP permit extending the DAC and MAC policies by adding
additional rules such as capability-based ones, but I'd normally expect
that to cause more work instead of less when evaluating since all claims
related to that policy would then need to be sufficiently tested and
verified. But I think that's getting off-topic for this list.
> 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.
Sorry, I blame lack of caffeine for that mixup. The requirement I meant
was that each auditable event needs to be associated with the identity of
the user that caused the event. In the context of this discussion, that
means that the login UID in audit records needs to correspond to the user
identity of the user on whose behalf the process (subject) runs.
For cron/at and other indirect execution methods, the daemon running the
jobs needs to be able to correctly associate the login UID of the user
who submitted the job with the audit records generated by that job.
Usually such daemons will need the capability to change the login UID for
forked processes in addition to generating user messages with a specific
login UID included in the record, so the distinction between those two
capabilities isn't all that useful in this case.
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.
Hmmm, this doesn't match the application note for FAU_SAR.1 in CAPP and
LSPP that mentions that it is expected that a single tool will exist that
satisfies all the various requirements related to audit information
access. Of course application notes aren't normative, and you could claim
that "grep" is the single tool usable for all types of audit trail
access...
-Klaus
7255
days inactive
7255
days old
linux-audit@lists.linux-audit.osci.io
4 comments
4 participants
participants (4)
-
Casey Schaufler -
Chad Hanson -
David Woodhouse -
Klaus Weidner