[RFC][PATCH] important new audit field
by Timothy R. Chavez
diff -Nurp linux-2.6.12-rc2-mm1~audit/kernel/auditsc.c linux-2.6.12-rc2-mm1~42/kernel/auditsc.c
--- linux-2.6.12-rc2-mm1~audit/kernel/auditsc.c 2005-04-05 13:16:26.000000000 -0500
+++ linux-2.6.12-rc2-mm1~42/kernel/auditsc.c 2005-04-05 17:38:12.000000000 -0500
@@ -642,6 +642,7 @@ static void audit_log_exit(struct audit_
audit_log_format(ab, " success=%s exit=%ld",
(context->return_valid==AUDITSC_SUCCESS)?"yes":"no",
context->return_code);
+ audit_log_format(ab, " the_answer_to_life_the_universe_and_everything=42");
audit_log_format(ab,
" a0=%lx a1=%lx a2=%lx a3=%lx items=%d"
" pid=%d loginuid=%d uid=%d gid=%d"
Alright, sorry :) I'm going home now.
-tim
19 years, 8 months
Re: [RFC][PATCH 2/2] file system auditing
by David Woodhouse
On Tue, 2005-04-05 at 17:20 -0500, Timothy R. Chavez wrote:
> --- linux-2.6.12-rc2-mm1/security/selinux/nlmsgtab.c 2005-03-02 01:38:19.000000000 -0600
> +++ linux-2.6.12-rc2-mm1~audit/security/selinux/nlmsgtab.c 2005-04-05 13:16:26.000000000 -0500
> @@ -98,6 +98,8 @@ static struct nlmsg_perm nlmsg_audit_per
> { AUDIT_DEL, NETLINK_AUDIT_SOCKET__NLMSG_WRITE },
> { AUDIT_USER, NETLINK_AUDIT_SOCKET__NLMSG_WRITE },
> { AUDIT_LOGIN, NETLINK_AUDIT_SOCKET__NLMSG_WRITE },
> + { AUDIT_WATCH_INS, NETLINK_AUDIT_SOCKET__NLMSG_WRITE },
> + { AUDIT_WATCH_REM, NETLINK_AUDIT_SOCKET__NLMSG_WRITE },
> };
Do you not need to add AUDIT_WATCH_LIST to this?
--
dwmw2
19 years, 8 months
dun dun dun
by Timothy R. Chavez
it's on fsdevel... i hope i didn't botch anything up ;)
anyway, i'm taking the night off... and will start making the changes we've
discussed with regards to passing information to and from the kernel. i'll
make a reply to your last message, steve, on watch listing, tommorow.
-tim
19 years, 8 months
Re: watch structure
by Casey Schaufler
--- Stephen Smalley <sds(a)tycho.nsa.gov> wrote:
> > That would require two copyins, one to get the
> > lengths and another to get the "buf". Not that
> > that's necessarily a stopper, but I had assumed
> > the goal was a one-shot interface.
>
> No, the whole thing is sent as a single buffer that
> is copied into the
> kernel once.
But you don't know how much to copy. If you
decide on a fixed amount you may as well use
the previously discussed structure.
> buf[0] at the end of a structure is
> common practice to
> reference data stuffed directly at the end of the
> structure.
Yup, and I'd have suggested it myself save for
the two copy problem.
Casey Schaufler
casey(a)schaufler-ca.com
__________________________________
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250
19 years, 8 months
[Fwd: Re: 2.6.12-rc2-mm1]
by Stephen Smalley
FYI.
-------- Forwarded Message --------
From: Christoph Hellwig <hch(a)infradead.org>
To: Andrew Morton <akpm(a)osdl.org>
Cc: linux-kernel(a)vger.kernel.org
Subject: Re: 2.6.12-rc2-mm1
Date: Tue, 5 Apr 2005 08:45:30 +0100
> bk-audit.patch
This introduces various AUDIT_ARCH numerical constants, which is a blatantly
stupid idea. We already have a way to uniquely identify architectures, and
that's the ELF headers, no need for another parallel namespace.
(btw, could you please add to all patches who's responsible for them,
bk-audit.patch doesn't tell)
19 years, 8 months
Re: watch structure
by Casey Schaufler
--- Stephen Smalley <sds(a)tycho.nsa.gov> wrote:
> On Tue, 2005-04-05 at 08:00 -0700, Casey Schaufler
> wrote:
> > But you don't know how much to copy. If you
> > decide on a fixed amount you may as well use
> > the previously discussed structure.
>
> I think that this is just a communication problem
> between you and me;
> the program knows the total length of the buffer,
> and passes it to the
> sendto() call when sending the buffer to the netlink
> socket.
Doh! My bad. I was thinking in terms of a syscall
interface, not a socket. Stephen is right.
The buf[0] scheme will work just fine.
Casey Schaufler
casey(a)schaufler-ca.com
__________________________________
Do you Yahoo!?
Make Yahoo! your home page
http://www.yahoo.com/r/hs
19 years, 8 months
watch structure
by Steve Grubb
Hello,
The way that the watch list is passed back currently is a string. This
diminishes its usefullness. The way it should really be passed back is in a
structure. This allows each part to have meaning (without parsing) and be
formatted in userspace as needed. The only problem is the structure is
defined as follows:
struct audit_watch {
uint32_t namelen;
uint32_t fklen;
char *name;
char *filterkey;
uint32_t perms;
};
name and filterkey are pointers. If we changed the structure to this:
struct audit_watch {
uint32_t namelen;
uint32_t fklen;
char name[MAX_PATH];
char filterkey[MAX_KEY_LEN];
uint32_t perms;
};
Then the structure can be used bi-directionally. Which brings up another
point...when the watch is being sent into the kernel, what guarantee do we
have that the app doesn't dissappear by the time the netlink packet is
dispositioned and the pointers dereferenced?
-Steve
19 years, 8 months
Re: watch structure
by Casey Schaufler
--- Stephen Smalley <sds(a)tycho.nsa.gov> wrote:
> The structure could just define the length and perms
> fields, then put a
> char buf[0]; at the end to allow referencing of
> watch->buf, and just
> include the two strings immediately after the
> structure when creating
> it. Kernel can then extract them appropriately
> based on the lengths.
> No need to reserve fixed size fields for them.
That would require two copyins, one to get the
lengths and another to get the "buf". Not that
that's necessarily a stopper, but I had assumed
the goal was a one-shot interface.
Casey Schaufler
casey(a)schaufler-ca.com
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
19 years, 8 months
[PATCH] fix ia64 syscall auditing
by Amy Griffis
Hello,
Attached is a patch against David's audit.17 kernel that adds checks
for the TIF_SYSCALL_AUDIT thread flag to the ia64 system call and
signal handling code paths. The patch enables auditing of system
calls set up via fsys_bubble_down, as well as ensuring that
audit_syscall_exit() is called on return from sigreturn.
Neglecting to check for TIF_SYSCALL_AUDIT at these points results in
incorrect information in audit_context, causing frequent system panics
when system call auditing is enabled on an ia64 system.
I have tested this patch and have seen no problems with it.
Thanks,
Amy
19 years, 9 months
[RFC][PATCH 0/3] CAPP-compliant file system auditing
by Timothy R. Chavez
Hello,
.:: Introduction ::.
In its present state, the Linux audit subsystem cannot be used in a Common
Criteria (ISO/IEC 15408)[1] CAPP/EAL4+[2] evaluation. This patch addresses a
blocking deficiency in the current implementation regarding the inability to
audit file system objects by "name". Currently, one is limited to using a
(inode,device) filter rule to audit syscall access to the object. This is
insufficient for CAPP because (1) the object is not being audited by "name"
nor (2) will it remain auditable if the underlying inode changes. What
follows from this requirement is the ability to better observe the _behavior_
of the "named" object, rather then just access to the "named" object.
Here is a relevant example show casing the deficiency:
The administrator audits "/etc/shadow". To do so, she adds the filter rule
using /etc/shadow's current inode and device. Then, she runs 'passwd' to
change her password. She consults the audit log and sees that some records
have been generated, but when she runs 'passwd' again, she notices that no
longer are audit records being generated. She does an 'ls -i /etc/shadow'
and notices that the inode has changed. She then decides to consult the
audit log and comes to the realization that what's there is incomplete and
does not tell the complete story of /etc/shadow during the execuation of
'passwd'.
The patch is broken into two parts.
Part 1: The actual implementation of the file system auditing piece
Part 2: The hooks
+ + + +
[1] Common Criteria is an internationally recognized ISO centered around IT
security evaluations (http://csrc.nist.gov/cc/)
[2] CAPP/EAL4 (Controlled Access Protection Profile)/Evaluation Assurance
Level 4+ is for generalized environments with a moderate level of risk to the
assets. For more information about CAPP requirements:
http://www.commoncriteriaportal.org/public/files/ppfiles/capp.pdf)
-tim
19 years, 9 months
