7:51 p.m.
My system isn't leaking as badly after the first patch, but I still
currently have about 174,000+ leaked size-32 from <ipcperms+0xf/0x91>
after about an hour's uptime.
Looks like if audit_ipc_context() is called from elsewhere in kernel/auditsc.c,
it's cleaned up after. However, the call from ipc/util.c in ipcperms() doesn't
seem to get cleaned up after (and, in fact, it isn't clear why it's even called
there, at least to me...)
diff --git a/ipc/util.c b/ipc/util.c
index 8626219..e37e1e9 100644
--- a/ipc/util.c
+++ b/ipc/util.c
@@ -27,6 +27,7 @@
#include <linux/workqueue.h>
#include <linux/seq_file.h>
#include <linux/proc_fs.h>
+#include <linux/audit.h>
#include <asm/unistd.h>
@@ -468,6 +469,7 @@ int ipcperms (struct kern_ipc_perm *ipcp
{ /* flag will most probably be 0 or S_...UGO from <linux/stat.h> */
int requested_mode, granted_mode;
+ audit_ipc_context(ipcp);
requested_mode = (flag >> 6) | (flag >> 3) | flag;
granted_mode = ipcp->mode;
if (current->euid == ipcp->cuid || current->euid == ipcp->uid)
Looks like the source of my problem...
3:54 p.m.
On Friday 24 February 2006 20:51, Valdis.Kletnieks(a)vt.edu wrote:
However, the call from ipc/util.c in ipcperms() doesn't seem to
get cleaned
up after (and, in fact, it isn't clear why it's even called there, at least
to me...)
I don't see any reason for it either. The attached patch removes the
offending line and since it is not called outside of auditsc.c, we should
make it private to that file.
Signed-off-by: Steve Grubb <sgrubb(a)redhat.com>
diff -urp linux-2.6.15.x86_64.orig/include/linux/audit.h
linux-2.6.15.x86_64/include/linux/audit.h
--- linux-2.6.15.x86_64.orig/include/linux/audit.h 2006-02-25 16:39:08.000000000 -0500
+++ linux-2.6.15.x86_64/include/linux/audit.h 2006-02-25 16:36:38.000000000 -0500
@@ -320,7 +320,6 @@ extern int audit_socketcall(int nargs, u
extern int audit_sockaddr(int len, void *addr);
extern int audit_avc_path(struct dentry *dentry, struct vfsmount *mnt);
extern void audit_signal_info(int sig, struct task_struct *t);
-extern char *audit_ipc_context(struct kern_ipc_perm *ipcp);
extern int audit_set_macxattr(const char *name);
#else
#define audit_alloc(t) ({ 0; })
@@ -340,7 +339,6 @@ extern int audit_set_macxattr(const char
#define audit_sockaddr(len, addr) ({ 0; })
#define audit_avc_path(dentry, mnt) ({ 0; })
#define audit_signal_info(s,t) do { ; } while (0)
-#define audit_ipc_context(i) do { ; } while (0)
#define audit_set_macxattr(n) do { ; } while (0)
#endif
diff -urp linux-2.6.15.x86_64.orig/ipc/util.c linux-2.6.15.x86_64/ipc/util.c
--- linux-2.6.15.x86_64.orig/ipc/util.c 2006-02-25 16:39:18.000000000 -0500
+++ linux-2.6.15.x86_64/ipc/util.c 2006-02-25 16:36:13.000000000 -0500
@@ -27,7 +27,6 @@
#include <linux/workqueue.h>
#include <linux/seq_file.h>
#include <linux/proc_fs.h>
-#include <linux/audit.h>
#include <asm/unistd.h>
@@ -469,7 +468,6 @@ int ipcperms (struct kern_ipc_perm *ipcp
{ /* flag will most probably be 0 or S_...UGO from <linux/stat.h> */
int requested_mode, granted_mode;
- audit_ipc_context(ipcp);
requested_mode = (flag >> 6) | (flag >> 3) | flag;
granted_mode = ipcp->mode;
if (current->euid == ipcp->cuid || current->euid == ipcp->uid)
diff -urp linux-2.6.15.x86_64.orig/kernel/auditsc.c linux-2.6.15.x86_64/kernel/auditsc.c
--- linux-2.6.15.x86_64.orig/kernel/auditsc.c 2006-02-25 16:39:18.000000000 -0500
+++ linux-2.6.15.x86_64/kernel/auditsc.c 2006-02-25 16:38:12.000000000 -0500
@@ -1146,6 +1146,38 @@ uid_t audit_get_loginuid(struct audit_co
return ctx ? ctx->loginuid : -1;
}
+static char *audit_ipc_context(struct kern_ipc_perm *ipcp)
+{
+ struct audit_context *context = current->audit_context;
+ char *ctx = NULL;
+ int len = 0;
+
+ if (likely(!context))
+ return NULL;
+
+ len = security_ipc_getsecurity(ipcp, NULL, 0);
+ if (len == -EOPNOTSUPP)
+ goto ret;
+ if (len < 0)
+ goto error_path;
+
+ ctx = kmalloc(len, GFP_ATOMIC);
+ if (!ctx)
+ goto error_path;
+
+ len = security_ipc_getsecurity(ipcp, ctx, len);
+ if (len < 0)
+ goto error_path;
+
+ return ctx;
+
+error_path:
+ kfree(ctx);
+ audit_panic("error in audit_ipc_context");
+ret:
+ return NULL;
+}
+
/**
* audit_ipc_perms - record audit data for ipc
* @qbytes: msgq bytes
@@ -1179,38 +1211,6 @@ int audit_ipc_perms(unsigned long qbytes
return 0;
}
-char *audit_ipc_context(struct kern_ipc_perm *ipcp)
-{
- struct audit_context *context = current->audit_context;
- char *ctx = NULL;
- int len = 0;
-
- if (likely(!context))
- return NULL;
-
- len = security_ipc_getsecurity(ipcp, NULL, 0);
- if (len == -EOPNOTSUPP)
- goto ret;
- if (len < 0)
- goto error_path;
-
- ctx = kmalloc(len, GFP_ATOMIC);
- if (!ctx)
- goto error_path;
-
- len = security_ipc_getsecurity(ipcp, ctx, len);
- if (len < 0)
- goto error_path;
-
- return ctx;
-
-error_path:
- kfree(ctx);
- audit_panic("error in audit_ipc_context");
-ret:
- return NULL;
-}
-
/**
* audit_socketcall - record audit data for sys_socketcall
* @nargs: number of args
11:31 a.m.
On Sat, Feb 25, 2006 at 04:54:14PM -0500, Steve Grubb wrote:
On Friday 24 February 2006 20:51, Valdis.Kletnieks(a)vt.edu wrote:
> However, the call from ipc/util.c in ipcperms() doesn't seem to
> get cleaned up after (and, in fact, it isn't clear why it's even
> called there, at least to me...)
I don't see any reason for it either. The attached patch removes the
offending line and since it is not called outside of auditsc.c, we
should make it private to that file.
You are correct that the code as written isn't doing anything other
than leaking memory. However, it was intended to collect labels for
message queues during calls to msgget(), msgrcv(), msgsnd(), etc. The
audit_ipc_perms() hook is only collecting labels (and attempted perm
settings) from IPC_SET operations.
This call shouldn't be removed, it should be storing the retrieved
label in the appropriate place in the audit context. The label would
then be freed in audit_free_aux().
It should also be noted that there was some discussion on whether
ipcperms() was really the right place for audit to hook. See:
https://www.redhat.com/archives/linux-audit/2005-October/msg00041.html
https://www.redhat.com/archives/linux-audit/2005-October/msg00043.html
https://www.redhat.com/archives/linux-audit/2005-October/msg00044.html
To my knowledge, this was never investigated/resolved.
Regards,
Amy
5:03 p.m.
On Mon, 2006-02-27 at 12:31 -0500, Amy Griffis wrote:
You are correct that the code as written isn't doing anything
other
than leaking memory.
Unfortunately, that's right. The call to audit_ipc_context(ipcp) in
ipc/util.c returns a kmalloc'ed char * that isn't stored anywhere and
quite clearly leaks memory.
I set off on a search through the mailing list posts and my locally
stored patch revisions to determine how something like that slipped
through.
See the post:
https://www.redhat.com/archives/linux-audit/2005-October/msg00051.html
On Wed, 19 Oct 2005 16:39:21 -0500, I wrote:
- This patch reduced some of the verbage required for several
functions
and variables. In several places, "security_context" was replaced with
"context", such as
s/audit_ipc_security_context/audit_ipc_context/g
s/audit_log_task_security_context/audit_log_task_context/g
s/audit_aux_data_security_context/audit_aux_data_context/g
s/audit_inode_security_context/audit_inode_context/g
Additionally, the audit_names data structure uses char *ctx instead of
char *security_context now (which fits in more with gid,rdev,flags,
etc).
Please let me know if anyone is offended by these unrequested changes.
If this seems good enough to start testing, I'd like to see David merge
into his try by the end of the week. Thanks!
A couple of things happened that evidently flew under the radar with no
one screaming until now.
1) audit_ipc_perms() got struct kern_ipc_perm *ipcp added as the last
parameter
2) audit_ipc_security_context() was renamed to audit_ipc_context()
3) audit_ipc_context() was changed to return a char * of the context
string, which is called by audit_ipc_perms() (and helped clean up some
of the code in that function)
At this point, I neglected to kill the call to audit_ipc_context() in
ipc/util.c. Since each call to audit_ipc_perms() was now also passing
struct kern_ipc_perm *ipcp, the call in ipc/util.c was not needed.
As such, I ack Steve's patch. It is appropriate to delete the call to
audit_ipc_context() and furthermore make audit_ipc_context() local to
kernel/auditsc.c.
However, it was intended to collect labels for
message queues during calls to msgget(), msgrcv(), msgsnd(), etc. The
audit_ipc_perms() hook is only collecting labels (and attempted perm
settings) from IPC_SET operations.
I talked to Klaus about this and I expect him to pipe in right here...
In a nutshell, I was advised back in October that for certification
purposes, we're only required to audit ipc operations involving
security-relevant permissions checks (similar to our certification
requirements on syscall auditing). This is Klaus's area, though, so
I'll defer to his expertise here.
This call shouldn't be removed, it should be storing the
retrieved
label in the appropriate place in the audit context. The label would
then be freed in audit_free_aux().
This should be happening in the calls in:
ipc/msg.c, ipc/sem.c, ipc/shm.c:
audit_ipc_perms(setbuf.qbytes, setbuf.uid, setbuf.gid, setbuf.mode,
ipcp)
which calls audit_ipc_context() and gets the security context and stores
it in a (later freed) auxiliary context.
:-Dustin
6:06 p.m.
On Mon, Feb 27, 2006 at 05:03:28PM -0600, Dustin Kirkland wrote:
> However, it was intended to collect labels for
> message queues during calls to msgget(), msgrcv(), msgsnd(), etc. The
> audit_ipc_perms() hook is only collecting labels (and attempted perm
> settings) from IPC_SET operations.
I talked to Klaus about this and I expect him to pipe in right here...
In a nutshell, I was advised back in October that for certification
purposes, we're only required to audit ipc operations involving
security-relevant permissions checks (similar to our certification
requirements on syscall auditing).
The calls msgget(), msgrcv(), msgsnd(), etc. are doing permission
checks. How are these not security-relevant?
Klaus, if you could explain this I would appreciate it.
Thanks,
Amy
2:27 p.m.
On Mon, Feb 27, 2006 at 07:06:56PM -0500, Amy Griffis wrote:
On Mon, Feb 27, 2006 at 05:03:28PM -0600, Dustin Kirkland wrote:
> > However, it was intended to collect labels for
> > message queues during calls to msgget(), msgrcv(), msgsnd(), etc. The
> > audit_ipc_perms() hook is only collecting labels (and attempted perm
> > settings) from IPC_SET operations.
>
> I talked to Klaus about this and I expect him to pipe in right here...
>
> In a nutshell, I was advised back in October that for certification
> purposes, we're only required to audit ipc operations involving
> security-relevant permissions checks (similar to our certification
> requirements on syscall auditing).
The calls msgget(), msgrcv(), msgsnd(), etc. are doing permission
checks. How are these not security-relevant?
Klaus, if you could explain this I would appreciate it.
The discussion in this thread by Stephan Mueller and Stephen Smalley
covers this already, here's my two cents.
We have the following separate requirements:
a) [CAPP and LSPP]: audit the object identity - this happens always since
it's an integer argument to the IPC call and automatically saved by
syscall audit.
b) [CAPP and LSPP]: save additional data from system call pointer
arguments - this is only needed for *ctl() calls that change permissions
or other security attributes. I think that was the topic of discussion
back in October.
c) [LSPP]: save the subject label - I think this also happens
automatically.
d) [LSPP]: save the object label - that's what all the extra hooks are
needed for, since that's required for all operations on IPC objects.
(Also information flow decisions but that is mostly equivalent here).
I like Stephen's proposal to handle (d) from the SELinux hook, since
that's relevant for LSPP systems only, and this way it avoids intrusive
changes to the IPC code. (a) and (b) should still keep working in CAPP
systems without SELinux enabled.
-Klaus
5:37 p.m.
On Tue, 2006-02-28 at 14:27 -0600, Klaus Weidner wrote:
The discussion in this thread by Stephan Mueller and Stephen Smalley
covers this already, here's my two cents.
We have the following separate requirements:
a) [CAPP and LSPP]: audit the object identity - this happens always since
it's an integer argument to the IPC call and automatically saved by
syscall audit.
b) [CAPP and LSPP]: save additional data from system call pointer
arguments - this is only needed for *ctl() calls that change permissions
or other security attributes. I think that was the topic of discussion
back in October.
c) [LSPP]: save the subject label - I think this also happens
automatically.
d) [LSPP]: save the object label - that's what all the extra hooks are
needed for, since that's required for all operations on IPC objects.
(Also information flow decisions but that is mostly equivalent here).
I like Stephen's proposal to handle (d) from the SELinux hook, since
that's relevant for LSPP systems only, and this way it avoids intrusive
changes to the IPC code. (a) and (b) should still keep working in CAPP
systems without SELinux enabled.
Klaus- are you calling the audit_ipc_perms() calls in ipc/*c too
intrusive? Does this recommendation gel with the current popular
opinion? Does this mean that the current audit_ipc_perms() calls in
ipc/*c should be moved into the SELinux code, or rather that additional
code is required in the SELinux code?
As I understand it, the code as it stands in Viro's git tree performs
all of (a), (b), (c), and (d) sufficiently for collecting the context
of IPC objects, as well as the subject contexts of the initiating
syscalls for LSPP certification.
At this point, I'm trying to understand if there are additional to-do's
beyond the memory leak patch submitted by Steve Grubb and ack'ed by me
earlier in this thread. If there are, please specify, and if not,
please apply the memory leak patch and let's move on. I'd like to hear
Al's opinion on the matter, as the audit tree is his now and it's up to
him whether or not to push on to Andrew.
:-Dustin
7:02 p.m.
On Tue, Feb 28, 2006 at 05:37:40PM -0600, Dustin Kirkland wrote:
Klaus- are you calling the audit_ipc_perms() calls in ipc/*c too
intrusive? Does this recommendation gel with the current popular
opinion? Does this mean that the current audit_ipc_perms() calls in
ipc/*c should be moved into the SELinux code, or rather that additional
code is required in the SELinux code?
As I understand it, the code as it stands in Viro's git tree performs
all of (a), (b), (c), and (d) sufficiently for collecting the context
of IPC objects, as well as the subject contexts of the initiating
syscalls for LSPP certification.
I'm not asking for any specific change, and if the current code's
maintainer is happy with the hooks as implemented now that's fine. I was
just saying that putting strictly label related functionality into the
SELinux part of the code sounds like a reasonable way to implement it,
but that would be more along the line of a janitorial change if people
prefer that approach. We're not going for EAL8 with requirements for
maximally elegant and beautiful code ;)
At this point, I'm trying to understand if there are additional
to-do's
beyond the memory leak patch submitted by Steve Grubb and ack'ed by me
earlier in this thread. If there are, please specify, and if not,
please apply the memory leak patch and let's move on. I'd like to hear
Al's opinion on the matter, as the audit tree is his now and it's up to
him whether or not to push on to Andrew.
I'm not aware of anything additional needed. I haven't tested the code,
and am not very familiar with it, so I can't definitely promise that it
currently meets all the requirements, but that's what the testing process
is for.
-Klaus
8:04 p.m.
>> At this point, I'm trying to understand if there are
additional to-do's
>> beyond the memory leak patch submitted by Steve Grubb and ack'ed by me
>> earlier in this thread. If there are, please specify, and if not,
>> please apply the memory leak patch and let's move on. I'd like to hear
>> Al's opinion on the matter, as the audit tree is his now and it's up to
>> him whether or not to push on to Andrew.
I'm not aware of anything additional needed. I haven't tested the code,
and am not very familiar with it, so I can't definitely promise that it
currently meets all the requirements, but that's what the testing process
is for.
So the next steps are:
1) apply the memory leak patch to the lspp kernel
2) test that the requirements are (still) met
3) push the patch further along
Is that the right order or are we doing 1), 3) and then 2), fixing
after the fact if necessary?
-- ljk
12:52 p.m.
On Tue, Feb 28, 2006 at 05:37:40PM -0600, Dustin Kirkland wrote:
As I understand it, the code as it stands in Viro's git tree
performs
all of (a), (b), (c), and (d) sufficiently for collecting the context
of IPC objects, as well as the subject contexts of the initiating
syscalls for LSPP certification.
Please take a closer look at the code. The function that is
collecting the ipc object label -- audit_ipc_context() -- is called in
two places: audit_ipc_perms() and ipcperms().
audit_ipc_perms() is invoked during the following operations:
msgctl - IPC_SET
semctl - IPC_SET
shmctl - IPC_SET
ipcperms() is invoked during the following operations:
msgctl - IPC_STAT
msgsnd
msgrcv
semget
semctl - SEM_STAT
semctl - SETALL
semtimedop
shmget
shmctl - IPC_STAT
shmat
If you remove the audit_ipc_context() call from ipcperms() you will
not be collecting object labels for the second set of operations.
This does not meet LSPP requirements.
Your patch claims to collect object labels for ipc operations. But
since it only attaches the label to the audit context for the IPC_SET
calls, it does not do what it claims. At a minimum, your patch needs
to be fixed to attach the object label to the audit context for the
second set of operations.
Regards,
Amy
2:39 p.m.
On Wed, 2006-03-01 at 13:52 -0500, Amy Griffis wrote:
Please take a closer look at the code. The function that is
collecting the ipc object label -- audit_ipc_context() -- is called in
two places: audit_ipc_perms() and ipcperms().
audit_ipc_perms() is invoked during the following operations:
msgctl - IPC_SET
semctl - IPC_SET
shmctl - IPC_SET
ipcperms() is invoked during the following operations:
msgctl - IPC_STAT
msgsnd
msgrcv
semget
semctl - SEM_STAT
semctl - SETALL
semtimedop
shmget
shmctl - IPC_STAT
shmat
If you remove the audit_ipc_context() call from ipcperms() you will
not be collecting object labels for the second set of operations.
This does not meet LSPP requirements.
Your patch claims to collect object labels for ipc operations. But
since it only attaches the label to the audit context for the IPC_SET
calls, it does not do what it claims. At a minimum, your patch needs
to be fixed to attach the object label to the audit context for the
second set of operations.
Thank you, this is the analysis that I was looking for.
I'm in-lining a simple patch that solves memory leak and collects the
required information. Rather than calling audit_ipc_context() which
allocates memory and returns a char * which was being lost, ipcperms()
instead calls audit_ipc_perms(), which wraps audit_ipc_context() thereby
storing the context in an auxiliary IPC audit record. This happens each
and every time ipcperms() is called.
Note that the first argument of audit_ipc_perms() is qbytes, which I've
zero'd out inside of ipcperms() as that information is not available
within the scope of the ipcperms() function. Is that ok?
One more note... I'm attaching a short blip of test code that runs
through each of the msg* calls Amy mentions above. The code doesn't do
anything useful with IPC msg's, but I used it to verify that audit
messages are generated and subj/obj labels are collected.
Thanks.
:-Dustin
diff --git a/ipc/util.c b/ipc/util.c
index e37e1e9..07fff36 100644
--- a/ipc/util.c
+++ b/ipc/util.c
@@ -469,7 +469,7 @@ int ipcperms (struct kern_ipc_perm *ipcp
{ /* flag will most probably be 0 or S_...UGO from <linux/stat.h> */
int requested_mode, granted_mode;
- audit_ipc_context(ipcp);
+ audit_ipc_perms(0, ipcp->uid, ipcp->gid, ipcp->mode, ipcp);
requested_mode = (flag >> 6) | (flag >> 3) | flag;
granted_mode = ipcp->mode;
if (current->euid == ipcp->cuid || current->euid == ipcp->uid)
9:20 a.m.
On Thu, 2006-03-02 at 14:39 -0600, Dustin Kirkland wrote:
I'm in-lining a simple patch that solves memory leak and collects
the
required information. Rather than calling audit_ipc_context() which
allocates memory and returns a char * which was being lost, ipcperms()
instead calls audit_ipc_perms(), which wraps audit_ipc_context() thereby
storing the context in an auxiliary IPC audit record. This happens each
and every time ipcperms() is called.
But ipcperms() isn't called on every IPC operation, in particular not
for the ones that apply uid ownership or capability tests rather than
mode checks, e.g. SHM_LOCK/UNLOCK. Compare the coverage of the
security_* hooks in the ipc code against the audit-related hooks. That
is why I suggested making a call to some audit hook for collecting the
IPC object context from every selinux_* IPC hook - that ensures coverage
without requiring additional audit hooks.
--
Stephen Smalley
National Security Agency
1:13 p.m.
On Mon, Mar 06, 2006 at 10:20:05AM -0500, Stephen Smalley wrote:
But ipcperms() isn't called on every IPC operation, in particular
not
for the ones that apply uid ownership or capability tests rather than
mode checks, e.g. SHM_LOCK/UNLOCK. Compare the coverage of the
security_* hooks in the ipc code against the audit-related hooks.
SHM_LOCK/UNLOCK doesn't look like an "operation on an object" from the
LSPP point of view (it doesn't read, write, create, destroy, change
permissions, or similar things), so I don't see a need to audit that one.
There may be a need to add new hooks for specific functions if they turn
out to require auditing, but offhand I'm not aware of any.
That is why I suggested making a call to some audit hook for
collecting
the IPC object context from every selinux_* IPC hook - that ensures
coverage without requiring additional audit hooks.
Keep in mind that LSPP requires audit records (including object labels)
for unsuccessful operations, and as far as I know an access request
that's rejected by DAC permissions won't call the selinux hook.
-Klaus
7:55 a.m.
On Mon, 2006-03-06 at 13:13 -0600, Klaus Weidner wrote:
On Mon, Mar 06, 2006 at 10:20:05AM -0500, Stephen Smalley wrote:
> But ipcperms() isn't called on every IPC operation, in particular not
> for the ones that apply uid ownership or capability tests rather than
> mode checks, e.g. SHM_LOCK/UNLOCK. Compare the coverage of the
> security_* hooks in the ipc code against the audit-related hooks.
SHM_LOCK/UNLOCK doesn't look like an "operation on an object" from the
LSPP point of view (it doesn't read, write, create, destroy, change
permissions, or similar things), so I don't see a need to audit that one.
There may be a need to add new hooks for specific functions if they turn
out to require auditing, but offhand I'm not aware of any.
Ok, I haven't seen any specific analysis document (or just a writeup)
that goes through the IPC operations and categorizes them in this way
for audit, which is why I've been a bit puzzled by (seeming) arbitrary
choices in the audit hooks. Not to say that such documents / writeups
don't exist, but I haven't seen them...
Keep in mind that LSPP requires audit records (including object
labels)
for unsuccessful operations, and as far as I know an access request
that's rejected by DAC permissions won't call the selinux hook.
True, so that does mean that we can't just leverage the SELinux hooks
for that purpose. Pity.
--
Stephen Smalley
National Security Agency
6:50 p.m.
New subject: IPC hooks [Re: Another slab size-32 leak 2.6.16-rc4-mm2]
On Tue, Mar 07, 2006 at 08:55:46AM -0500, Stephen Smalley wrote:
On Mon, 2006-03-06 at 13:13 -0600, Klaus Weidner wrote:
> SHM_LOCK/UNLOCK doesn't look like an "operation on an object" from
the
> LSPP point of view (it doesn't read, write, create, destroy, change
> permissions, or similar things), so I don't see a need to audit that one.
> There may be a need to add new hooks for specific functions if they turn
> out to require auditing, but offhand I'm not aware of any.
Ok, I haven't seen any specific analysis document (or just a writeup)
that goes through the IPC operations and categorizes them in this way
for audit, which is why I've been a bit puzzled by (seeming) arbitrary
choices in the audit hooks. Not to say that such documents / writeups
don't exist, but I haven't seen them...
The "FSP mapping" document used for Linux CAPP evaluations classifies
syscalls as security relevant or not.
The evaluator used it as one of the inputs to determine if test coverage
(including audit) was complete. The published ones I'm aware of are the
following for RHEL3 and SLES9, maybe someone could publish newer ones?
(hint, hint):
http://www.ibm.com/developerworks/library/os-ltc-security/
ftp://www6.software.ibm.com/software/developer/library/os-ltc-security/sl...
ftp://www6.software.ibm.com/software/developer/library/os-ltc-security/RH...
It doesn't specifically examine sub-operations of syscalls separately,
such as SHM_LOCK, so it may not be sufficient in this case. CAPP
obviously didn't care about labels, and the syscall itself was always
audited. So I guess this would need some case by case analysis :-(
It would be preferable to have a central point that guarantees that the
audit record will always be complete.
This gets us back to the discussion in October that Amy already referred
to. I had mentioned the *_checkid() and *get() functions which looked
like promising candidates for hooks since they always need to be called
before doing something to an object:
https://www.redhat.com/archives/linux-audit/2005-October/msg00041.html
I don't know the code well enough to know if that works or would have bad
side effects, any comments?
-Klaus
1:51 p.m.
On Thu, Mar 02, 2006 at 02:39:42PM -0600, Dustin Kirkland wrote:
I'm in-lining a simple patch that solves memory leak and collects
the
required information. Rather than calling audit_ipc_context() which
allocates memory and returns a char * which was being lost, ipcperms()
instead calls audit_ipc_perms(), which wraps audit_ipc_context() thereby
storing the context in an auxiliary IPC audit record. This happens
each and every time ipcperms() is called.
Note that the first argument of audit_ipc_perms() is qbytes, which I've
zero'd out inside of ipcperms() as that information is not available
within the scope of the ipcperms() function. Is that ok?
The collected values qbytes, uid, gid, and mode represent the settings
that the user is requesting to write for the IPC object in an IPC_SET
operation, not the values of the current settings. So in ipcperms()
you need to pass an invalid value for all four of those parameters. I
believe 0 is a valid setting for all of them, so you'll need a
different value.
On that note, you may also want to change the name audit_ipc_perms()
to reflect the fact that you are no longer gathering only the
requested perm settings, but object labels as well. E.g., audit_ipc()
is a more general name and would follow the other interfaces doing
similar things: audit_socketcall(), audit_sockaddr(), etc.
Amy
6863
days inactive
6874
days old
linux-audit@lists.linux-audit.osci.io
16 comments
7 participants
participants (7)
-
Amy Griffis -
Dustin Kirkland -
Klaus Weidner -
Linda Knippers -
Stephen Smalley -
Steve Grubb -
Valdis.Kletnieks＠vt.edu