Discussion:
[RFC] linux-2.6.10-auditfs-tc1.patch
(too old to reply)
Timothy R. Chavez
2005-01-19 23:55:54 UTC
Permalink
Hello,

Attached to this e-mail is my first iteration of the file system
auditing piece needed for CAPP EAL4. I appreciate all feedback, but
please read the TODO list prior to sending me feedback on something
I'm already aware of. I've not stressed tested this code nor have I
done any formal FVT. The testing I have done has been.. minimal.
I've mostly seen if given scenarios work (move one watched file to
another watched location, create a hardlink to /etc/passwd from
/home/me, etc).

At this time, I'm unable to provide you with the userspace patch I
wrote, but encourage someone on this list to add the functionality to
libaudit/auditctl and submit the patch (Steve :)?). If you'd like my
"guidance" please e-mail me privately.

ABOUT:

Thus far, the patch being submitted with this e-mail implements a
rudimentary file system auditing capability using the in-kernel audit
David Woodhouse
2005-01-20 13:32:27 UTC
Permalink
Can we make the i_audit field in struct inode dependent on
CONFIG_AUDITFILESYSTEM?

As I understand it, this watches only extant inodes. You can't watch for
attempts to read or create a non-existent file. Is that functionality
not required?

I'll refrain from heckling about locking since you mentioned it
yourself :)
--
dwmw2
Timothy R. Chavez
2005-01-20 15:47:11 UTC
Permalink
Post by David Woodhouse
Can we make the i_audit field in struct inode dependent on
CONFIG_AUDITFILESYSTEM?
Sure, I'm glad you pointed that out.
Post by David Woodhouse
As I understand it, this watches only extant inodes. You can't watch for
attempts to read or create a non-existent file. Is that functionality
not required?
I'm fairly sure that for CAPP, this capability is not required.
Granted, it would be useful for other types of auditing.

I'll test this when I get into work to make sure, but I believe that
this is kind of supported in the case where we try to <access> a file
that exists, but we don't have <access> too. We'll get a record for
the syscall and for the file (sharing the same serial number) and in
the record for the syscall, we should see the error code as its return
value right?

To log accesses on non-existent files, it'd probably be sufficient to
hook d_lookup. At that point I have my parent dentry/inode and know
my name. I can simply check to see if its being watched or not and if
it is, record the attempt.
Post by David Woodhouse
I'll refrain from heckling about locking since you mentioned it
yourself :)
Thanks :-)
Post by David Woodhouse
--
dwmw2
--
- Timothy R. Chavez
Klaus Weidner
2005-01-20 16:09:14 UTC
Permalink
Post by Timothy R. Chavez
Post by David Woodhouse
As I understand it, this watches only extant inodes. You can't watch for
attempts to read or create a non-existent file. Is that functionality
not required?
I'm fairly sure that for CAPP, this capability is not required.
Granted, it would be useful for other types of auditing.
The CAPP and LSPP requirements only concern access to objects, and a
nonexistent file isn't an object to which access needs to be monitored.
Post by Timothy R. Chavez
To log accesses on non-existent files, it'd probably be sufficient to
hook d_lookup. At that point I have my parent dentry/inode and know
my name. I can simply check to see if its being watched or not and if
it is, record the attempt.
Note that many programs will try to open tons of nonexistent files due to
various preconfigured locations for config files etc. Such access would
need to be filtered to be at all useful. But you mention that this could
be done via the watch list, which would solve this.

Auditing of failed attempts to create new files may be useful to find out
if someone is trying to create a ~/.ssh/authorized_keys file or something
else with a potential security impact. This should be a fairly rare
occurence, so I think a simple rule to audit all failed file creation
attempts would probably be sufficient. A full watch list based solution
would be optimal but I'd consider that to be a low priority.

-Klaus
David Woodhouse
2005-01-20 15:58:20 UTC
Permalink
Post by Timothy R. Chavez
Post by David Woodhouse
Can we make the i_audit field in struct inode dependent on
CONFIG_AUDITFILESYSTEM?
Sure, I'm glad you pointed that out.
You also have to do likewise in fs/inode.c, and fs/namei.c doesn't build
with CONFIG_AUDITFILESYSTEM disabled because it uses the return value of
audit_notify_watch().

You don't seem to be logging the _result_ of the permission() call, or
am I missing something?

--- ./fs/inode.c~ 2005-01-20 15:45:43.000000000 +0000
+++ ./fs/inode.c 2005-01-20 15:54:34.744093992 +0000
@@ -135,7 +135,9 @@ static struct inode *alloc_inode(struct
inode->i_cdev = NULL;
inode->i_rdev = 0;
inode->i_security = NULL;
+#ifdef CONFIG_AUDITFILESYSTEM
inode->i_audit = NULL;
+#endif
inode->dirtied_when = 0;
if (security_inode_alloc(inode)) {
if (inode->i_sb->s_op->destroy_inode)
--- ./include/linux/fs.h~ 2005-01-20 15:53:54.635065632 +0000
+++ ./include/linux/fs.h 2005-01-20 15:53:27.413077728 +0000
@@ -1,4 +1,4 @@
-##ifndef _LINUX_FS_H
+#ifndef _LINUX_FS_H
#define _LINUX_FS_H

/*
@@ -451,7 +451,9 @@ struct inode {
#ifdef CONFIG_QUOTA
struct dquot *i_dquot[MAXQUOTAS];
#endif
+#ifdef CONFIG_AUDITFILESYSTEM
struct audit_data *i_audit;
+#endif
/* These three should probably be a union */
struct list_head i_devices;
struct pipe_inode_info *i_pipe;
--- ./include/linux/audit.h~ 2005-01-20 15:45:43.000000000 +0000
+++ ./include/linux/audit.h 2005-01-20 15:49:20.346091408 +0000
@@ -188,7 +188,7 @@ extern int audit_notify_watch(struct tas
#define audit_putname(n) do { ; } while (0)
#define audit_inode(n,i,d) do { ; } while (0)
#define audit_get_loginuid(c) ({ -1; })
-#define audit_notify_watch(t,i,m) do { ; } while(0)
+#define audit_notify_watch(t,i,m) ({ 0; })
#endif

#ifdef CONFIG_AUDITFILESYSTEM
--
dwmw2
Timothy R. Chavez
2005-01-20 17:05:14 UTC
Permalink
Post by David Woodhouse
Post by Timothy R. Chavez
Post by David Woodhouse
Can we make the i_audit field in struct inode dependent on
CONFIG_AUDITFILESYSTEM?
Sure, I'm glad you pointed that out.
You also have to do likewise in fs/inode.c, and fs/namei.c doesn't build
with CONFIG_AUDITFILESYSTEM disabled because it uses the return value of
audit_notify_watch().
Doh! Thanks
Post by David Woodhouse
You don't seem to be logging the _result_ of the permission() call, or
am I missing something?
Good question, actually. I just did a test and tried to cp a user
file into /etc at a watched location, and it logs the syscall and
attempted file access, and in theory the exit (return_value) of the
syscall should be negative, upon failure, right? And this should tell
you the entire story ("Access to this <watched file>
<succeeded/failed>"). But its giving me some super large number in
the log as the exit/return code... Maybe I'm missing something, but
why is the return code being logged out with a %u and not a %d?

if (context->return_valid)
audit_log_format(ab, " exit=%u", context->return_code);

<snip>
Post by David Woodhouse
--
dwmw2
--
- Timothy R. Chavez
Steve Grubb
2005-01-20 17:12:46 UTC
Permalink
But its giving me some super large number in the log as the
exit/return code... Maybe I'm missing something, but why is
the return code being logged out with a %u and not a %d?
Yes, that should be a %d. The fix was sent in a patch Peter submitted
upstream. It was accepted into 2.6.11 which is now rc status.

-Steve
Timothy R. Chavez
2005-01-20 19:31:12 UTC
Permalink
Hello,

Just a note. I've detected a rather careless bug. When I switched
audit_watch from a void function to return an integer, the only case
where I'd get anything other then return of 0 would be if I failed on
memory allocation for a new inode->i_audit. However, this -ENOMEM was
not being handled because it can not be escalated. This being the
case, I'm having to rework the system and create a preallocation
stradegy that guarantees when I'm in audit_watch, I'll have the
necessary memory. This also allows me to handle the -ENOMEM case,
just at an earlier point.

I hope to have this done by today, RCU locking tonight or tommorow.
--
- Timothy R. Chavez
Chris Wright
2005-01-21 03:20:27 UTC
Permalink
Post by Timothy R. Chavez
rudimentary file system auditing capability using the in-kernel audit
subsystem.
Serge Hallyn
2005-01-21 15:50:30 UTC
Permalink
* Add RCU locking in the appropriate places to make SMP-safe
Is RCU a requirement, or just some real locking?
rwlocking should suffice for now, but eventually a spinlock to prevent
concurrent writers and rcu to prevent deletion of a watch entry while
another process is using it seems ideal.

Given his ambitious goals of doing locking overnight, I think rwlocks
are the way to go for now :)
Seems intuitively useful to at least be able to watch a file regardless
of who touched it, or what syscall was used. I think you'd especially
want to know if you had some non uid=0 process that wrote to a sensitive
file abusing it's CAP_DAC_OVERRIDE privilege for example.
Perhaps we should print out current->cap_effective? Or is that
overkill? Or perhaps an actual "security_identify_process(task, buf,
len)" hook would be useful, where commoncap could print out the
capabilities, and selinux could print out the context. Maybe that's
closer to debug info...
* Add/remove unnecessary information about the file or directory being
collected in the audit context. Input on this?
I missed which parts are unnecessary?
It sounds like he's worried about the 7 line audit_log_format line he
has, but I think that's all good info.

How do people feel about the general approach and limitations? For
instance, you can't ask to watch /etc/passwd if /etc does not yet
exist, or, if you ask to watch /etc/passwd, then mount another fs
over /etc, you quietly lose that watch entry. (Tim: please correct me
if I'm wrong) The alternative, however, is to deal with deeper
pathnames in the kernel, which is always frowned upon. Are we satisfied
with saying that 'mount' could be modified in userspace to do the right
thing in recreating watch entries? Perhaps we could even use inotify +
a userspace daemon for the mkdir /etc case, to create new audit entries
based on some config file. This goes beyond CAPP requirements (else
inotify would not suffice), and into what seems to me to be real world
usefulness.

-serge
Steve Grubb
2005-01-21 16:15:03 UTC
Permalink
Perhaps we should print out current->cap_effective?  Or is that
overkill?  Or perhaps an actual "security_identify_process(task, buf,
len)" hook would be useful, where commoncap could print out the
capabilities, and selinux could print out the context.  Maybe that's
closer to debug info...
Based on previous discussions, I think this would be required for LSPP. If we
are going for LSPP after meeting CAPP, it wouldn't be bad to start getting
some things in place.
It sounds like he's worried about the 7 line audit_log_format line he
has, but I think that's all good info.
I think I'd like to make a change to the way that the kernel sends netlink
packets. It would be far more efficient for log_end to send multiple records
in 1 packet instead of 7 separate packets. Especially if the admin has
configured for full sync writing.
 Are we satisfied with saying that 'mount' could be modified in
 userspace to do the right thing in recreating watch entries?
I don't think we can/should touch mount.
 Perhaps we could even use inotify + a userspace daemon for the mkdir
 /etc case, to create new audit entries based on some config file.
The audit daemon could be made to handle this. We just select on 2 different
descriptors & process accordingly. That is, if we need to do this...

-Steve
Darrel Goeddel
2005-01-21 16:37:15 UTC
Permalink
Post by Serge Hallyn
Perhaps we should print out current->cap_effective? Or is that
overkill? Or perhaps an actual "security_identify_process(task, buf,
len)" hook would be useful, where commoncap could print out the
capabilities, and selinux could print out the context. Maybe that's
closer to debug info...
This hook, and a similar security_identify_inode(...), hook will be necessary
for an LSM to go through a LSPP evaluation. The label information is required
to be included in the audit record for all subjects/objects/information involved
in the event. I have a quick-and-dirty patch that implemented this
functionality. Note that this patch uses pre-allocated 1K buffers (limits info
and sucks up a lot of memory). A proper memory allocation scheme needs to be
worked up and the patch probably needs to be rebased to newer code. I planned
on getting back to this in the near future. If someone else is working on this
functionality, please let me know, otherwise I can bump this up on my TODO list.

This patch also includes uid/gid/mode for filesystem objects. I felt that this
was a needed addition to determine the cause of filesystem related denials. Do
others agree with this addition to the records, and is there anything else that
we could possibly want?
--
Darrel
Chris Wright
2005-01-21 17:15:28 UTC
Permalink
[much easier to comment on patches if they are inline, and shorter lines
to keep linewrap down]
Post by Darrel Goeddel
Post by Serge Hallyn
Perhaps we should print out current->cap_effective? Or is that
overkill? Or perhaps an actual "security_identify_process(task, buf,
len)" hook would be useful, where commoncap could print out the
capabilities, and selinux could print out the context. Maybe that's
closer to debug info...
This hook, and a similar security_identify_inode(...), hook will be necessary
for an LSM to go through a LSPP evaluation. The label information is required
to be included in the audit record for all subjects/objects/information involved
in the event. I have a quick-and-dirty patch that implemented this
functionality. Note that this patch uses pre-allocated 1K buffers (limits info
and sucks up a lot of memory). A proper memory allocation scheme needs to be
worked up and the patch probably needs to be rebased to newer code. I planned
on getting back to this in the near future. If someone else is working on this
functionality, please let me know, otherwise I can bump this up on my TODO list.
This patch also includes uid/gid/mode for filesystem objects. I felt that this
was a needed addition to determine the cause of filesystem related denials. Do
others agree with this addition to the records, and is there anything else that
we could possibly want?
This would be redundant to the audit info that Tim's trying to push out.
Security label should stand alone, and be a simple string.
Post by Darrel Goeddel
- nd->dentry->d_inode->i_ino,
- nd->dentry->d_inode->i_rdev);
+ audit_inode(name, nd->dentry->d_inode);
Makes sense. But this is only for path lookup. Doesn't account, for
example, for the audit msg partway through failed path resolution --
failed for security reason, for example.
Post by Darrel Goeddel
return retval;
}
Index: include/linux/audit.h
===================================================================
RCS file: /source/cvsroots/fedora-cd/fedora-cd/src/linux-2.6/include/linux/audit.h,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 audit.h
--- include/linux/audit.h 26 May 2004 18:05:58 -0000 1.1.1.1
+++ include/linux/audit.h 12 Jan 2005 19:48:40 -0000
@@ -147,7 +147,9 @@ extern void audit_syscall_entry(struct t
extern void audit_syscall_exit(struct task_struct *task, int return_code);
extern void audit_getname(const char *name);
extern void audit_putname(const char *name);
-extern void audit_inode(const char *name, unsigned long ino, dev_t rdev);
+
+struct inode;
+extern void audit_inode(const char *name, struct inode *inode);
/* Private API (for audit.c only) */
extern int audit_receive_filter(int type, int pid, int uid, int seq,
@@ -162,7 +164,7 @@ extern int audit_set_loginuid(struct au
#define audit_syscall_exit(t,r) do { ; } while (0)
#define audit_getname(n) do { ; } while (0)
#define audit_putname(n) do { ; } while (0)
-#define audit_inode(n,i,d) do { ; } while (0)
+#define audit_inode(n,i) do { ; } while (0)
#endif
#ifdef CONFIG_AUDIT
Index: include/linux/security.h
===================================================================
RCS file: /source/cvsroots/fedora-cd/fedora-cd/src/linux-2.6/include/linux/security.h,v
retrieving revision 1.35
diff -u -p -r1.35 security.h
--- include/linux/security.h 11 Jan 2005 19:10:15 -0000 1.35
+++ include/linux/security.h 12 Jan 2005 19:48:40 -0000
@@ -413,6 +413,11 @@ struct open_request;
* the size of the buffer required.
* Returns number of bytes used/required on success.
+ * written to. You only have this much space and this call can not return
+ * an error, so manage the space wisely...
*
* Security hooks for file operations
*
@@ -632,6 +637,11 @@ struct open_request;
* security attributes, e.g. for /proc/pid inodes.
+ * written to. You only have this much space and this call can not return
+ * an error, so manage the space wisely...
This should simply get back a char*, and the caller is responsible for
freeing, or something like that. Also, this is needed for _every_ label,
not just inode and task. SELinux already has this function internally,
see getprocattr->security_sid_to_context. Perhaps a better solution is
to make the name be part of a label.

thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
Timothy R. Chavez
2005-01-21 17:57:37 UTC
Permalink
Hello,

Sorry for my recent inactivity, I've been consumed with fixing up all
the memory leaks / removing unnecessary code, adding the watch
reference counting, etc.

Thanks Chris and David for all the great feedback.

Anyway, if we want to make this thing dynamic so that we can add watch
points to paths that partially exist or do not exist at all and be
able to remap on new mounts, it's going to take quite a rework and the
reintroduction of something like Serge's mapnode data structure. Do
we want to shift directions again? All this oscillating between
requirements is starting to give me gray hair and I'm only 23 :( JK,
but seriously, can we converge on something :)?


Back to the grind stone.
--
- Timothy R. Chavez
Chris Wright
2005-01-21 18:29:47 UTC
Permalink
Post by Timothy R. Chavez
Anyway, if we want to make this thing dynamic so that we can add watch
points to paths that partially exist or do not exist at all and be
able to remap on new mounts, it's going to take quite a rework and the
reintroduction of something like Serge's mapnode data structure. Do
we want to shift directions again? All this oscillating between
requirements is starting to give me gray hair and I'm only 23 :( JK,
but seriously, can we converge on something :)?
There's two primary issues.

1) Make sure it satisfies basic CAPP requirements (I expect the dynamic
issue could be handled w/in CAPP by simply documenting for the admin
that mounts after audit is started aren't allowed). Of course, as
mentioned earlier, while we're here, might as well look out for LSPP,
but the audit requirements aren't that much different to my recollection,
just need to spit out labels...

2) Make the patch sane and mergeable. This could mean a bit of
oscialltion until the cleanest approach falls out. And may mean making
things sane compared with CAPP.

Now for updates, I think you'll need to keep watch of the whole tree,
mount issues aside. For example, I believe that right now the following
could fall off of the radar:

# mv /etc /tmp
# mkdir /etc
# cp /tmp/evil_shadow /etc/shadow

I think this would kill /etc dir watchpoints, and /etc/shadow would no
longer be watched, while /tmp/etc/shadow is diligently watched.

thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
Klaus Weidner
2005-01-21 19:41:03 UTC
Permalink
Post by Chris Wright
Now for updates, I think you'll need to keep watch of the whole tree,
mount issues aside. For example, I believe that right now the following
# mv /etc /tmp
# mkdir /etc
# cp /tmp/evil_shadow /etc/shadow
I think this would kill /etc dir watchpoints, and /etc/shadow would no
longer be watched, while /tmp/etc/shadow is diligently watched.
This type of thing is not a concern for CAPP and LSPP, since
administrators are still assumed to be trustworthy, and ordinary users
can't do that kind of thing. I'm not convinced that it's a real concern
in practical use either - an audit subsystem that could cope with
malicious administrators reliably would need to be designed differently.

I guess it would be possible to set up a watch list on "/" to monitor
renames/recreation of /etc though, which would at least give admins the
chance to notice this kind of thing happening.

-Klaus
Chris Wright
2005-01-21 19:49:27 UTC
Permalink
Post by Klaus Weidner
This type of thing is not a concern for CAPP and LSPP, since
administrators are still assumed to be trustworthy, and ordinary users
can't do that kind of thing. I'm not convinced that it's a real concern
in practical use either - an audit subsystem that could cope with
malicious administrators reliably would need to be designed differently.
Yes, that's the same conversation I was having with Tim. That will take
any mount issues off the table, as they are identical.
Post by Klaus Weidner
I guess it would be possible to set up a watch list on "/" to monitor
renames/recreation of /etc though, which would at least give admins the
chance to notice this kind of thing happening.
Right, that's what I meant by watching the whole tree.

thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
Serge Hallyn
2005-01-21 20:05:30 UTC
Permalink
Post by Timothy R. Chavez
Hello,
Sorry for my recent inactivity, I've been consumed with fixing up all
the memory leaks / removing unnecessary code, adding the watch
reference counting, etc.
Thanks Chris and David for all the great feedback.
Anyway, if we want to make this thing dynamic so that we can add watch
points to paths that partially exist or do not exist at all and be
able to remap on new mounts, it's going to take quite a rework and the
reintroduction of something like Serge's mapnode data structure.
No, I think we're talking about a user-space solution to the more
dynamic stuff. That shouldn't affect your kernel patch at all, right?\

I don't think doing it in the kernel would be upstreamable.
--
Serge Hallyn <***@us.ibm.com>
Chris Wright
2005-01-21 16:48:35 UTC
Permalink
Post by Serge Hallyn
* Add RCU locking in the appropriate places to make SMP-safe
Is RCU a requirement, or just some real locking?
rwlocking should suffice for now, but eventually a spinlock to prevent
concurrent writers and rcu to prevent deletion of a watch entry while
another process is using it seems ideal.
Yeah, guess that's a job for benchmarking.
Post by Serge Hallyn
Seems intuitively useful to at least be able to watch a file regardless
of who touched it, or what syscall was used. I think you'd especially
want to know if you had some non uid=0 process that wrote to a sensitive
file abusing it's CAP_DAC_OVERRIDE privilege for example.
Perhaps we should print out current->cap_effective? Or is that
overkill? Or perhaps an actual "security_identify_process(task, buf,
len)" hook would be useful, where commoncap could print out the
capabilities, and selinux could print out the context. Maybe that's
closer to debug info...
I agree with Steve, I think that LSPP would require security labels in
audit message.
Post by Serge Hallyn
* Add/remove unnecessary information about the file or directory being
collected in the audit context. Input on this?
I missed which parts are unnecessary?
It sounds like he's worried about the 7 line audit_log_format line he
has, but I think that's all good info.
I think you'll get interesting output with hardlinks. As in the path
used to establish the watchpoint to the inode, not the path used to
access the inode.
Post by Serge Hallyn
How do people feel about the general approach and limitations? For
instance, you can't ask to watch /etc/passwd if /etc does not yet
exist, or, if you ask to watch /etc/passwd, then mount another fs
over /etc, you quietly lose that watch entry.
Yes, so you'd either have to maintain watchlists all the way back to /,
and rebuild or keep this type of updating done in userspace. The latter
will be lossy. Also, you don't quite lose the watch entry, you should
keep it for the underlying /etc/passwd, which some apps may be using.
For example, one method of containment is to do bind mounts into a
private namespace. So mount --bind /dev/null /etc/passwd for some
contained process, access to /etc/passwd is pretty unintersting unless
it's the real underlying inode.
Post by Serge Hallyn
(Tim: please correct me
if I'm wrong) The alternative, however, is to deal with deeper
pathnames in the kernel, which is always frowned upon. Are we satisfied
with saying that 'mount' could be modified in userspace to do the right
thing in recreating watch entries?
I don't think we want to dig into pathnames. Mount could be modified,
but it'd have to be after the mount succeeded, so might as well use
notification.
Post by Serge Hallyn
Perhaps we could even use inotify +
a userspace daemon for the mkdir /etc case, to create new audit entries
based on some config file. This goes beyond CAPP requirements (else
inotify would not suffice), and into what seems to me to be real world
usefulness.
Speaking of inotify, what happened to trying to have some similar
mechanism? It'd be nice for audit to open an event channel that's fed
by a common mechanism to inotify.

thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
Casey Schaufler
2005-01-22 01:12:04 UTC
Permalink
Post by Darrel Goeddel
This patch also includes uid/gid/mode for filesystem
objects. I felt that this
was a needed addition to determine the cause of
filesystem related denials. Do
others agree with this addition to the records, and
is there anything else that
we could possibly want?
ACL?

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



__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail
Casey Schaufler
2005-01-22 01:19:16 UTC
Permalink
Post by Steve Grubb
Based on previous discussions, I think this would be
required for LSPP. If we
are going for LSPP after meeting CAPP, it wouldn't
be bad to start getting
some things in place.
Capabilties are fun in a CAPP environment, too.
The Irix CAPP system (for example) uses
capabilities and yes, they go in the audit trail
along with an indication of which capabilities were
required to perform the action, if any.

This is probably a bit late in the discussion,
but have y'all considered using a tokenized audit
record format? If you did you wouldn't have to
care if any given bit of information was there
just yet, or allocate a place for things that
might or might not be there someday. Both Solaris
and Irix use tokenized schemes to effect.


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

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Chris Wright
2005-01-22 01:33:47 UTC
Permalink
Post by Casey Schaufler
This is probably a bit late in the discussion,
but have y'all considered using a tokenized audit
record format? If you did you wouldn't have to
care if any given bit of information was there
just yet, or allocate a place for things that
might or might not be there someday. Both Solaris
and Irix use tokenized schemes to effect.
You mean BSM format? Yes, I think Serge and I talked about it briefly
a few months ago. The current method is tokenized and reasonably
extensible. It's not quite record+tokens like BSM, but there's an initial
record that tells you how many ancillary records (items) to expect.
And each record is made up primarily of token=value pairs. I think
we should provide what makes sense, and do any BSM type translation
in userspace. But having _some_ BSM compatibility would be wise, since
that's what many tools deal with.

thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
Steve Grubb
2005-01-24 15:51:16 UTC
Permalink
I think we should provide what makes sense, and do any BSM type
translation in userspace.  But having _some_ BSM compatibility
would be wise, since that's what many tools deal with.
I'd be happy to merge this into auditd. Send the patch to me or this mail
list.

-Steve Grubb
Steve Grubb
2005-01-24 15:43:57 UTC
Permalink
Post by Casey Schaufler
The Irix CAPP system (for example) uses
capabilities and yes, they go in the audit trail
along with an indication of which capabilities were
required to perform the action, if any.
Which capabilities? The capabilities of the process or the capability required
to successfully make the syscall? This would likely add a lot of text to the
message the kernel sends. I would have to say we can't do this unless there
is a certification requirement that we are trying to meet. Even then, maybe
something that's a bitmap might be all we can do.
Post by Casey Schaufler
This is probably a bit late in the discussion,
but have y'all considered using a tokenized audit
record format?
Yes. The audit program has a format_type configuration option so these can be
written. Send the patch to me or this mail list against the latest audit
daemon code.

-Steve Grubb
Casey Schaufler
2005-01-24 03:49:51 UTC
Permalink
Post by Chris Wright
You mean BSM format?
BSM is one example. Irix is another. They're
both based on a proposal presented to the POSIX
group by one W. Olin Sibert.
Post by Chris Wright
Yes, I think Serge and I
talked about it briefly
a few months ago. The current method is tokenized
and reasonably
extensible. It's not quite record+tokens like BSM,
but there's an initial
record that tells you how many ancillary records
(items) to expect.
This self describing behavior is what's important.
It allows you to throw in additional process and
file attributes (e.g. MAC labels, ACLs) as
necessary.
Post by Chris Wright
And each record is made up primarily of token=value
pairs.
Very good. If you document the legitimate tokens
and they kind of information in the value you're
a long way toward a useful audit system.
Post by Chris Wright
I think
we should provide what makes sense, and do any BSM
type translation
in userspace.
A reasonable option. That's how SGI dealt with
a major overhaul to the audit format in Irix6.5
Post by Chris Wright
But having _some_ BSM compatibility
would be wise, since
that's what many tools deal with.
At least a description of what's in the records
and tokens to make it easy for an individual who
is inclined to attempt such a translation is in
order.


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



__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail
Casey Schaufler
2005-01-24 16:29:00 UTC
Permalink
On Friday 21 January 2005 20:19, Casey Schaufler
Post by Casey Schaufler
The Irix CAPP system (for example) uses
capabilities and yes, they go in the audit trail
along with an indication of which capabilities
were
Post by Casey Schaufler
required to perform the action, if any.
Which capabilities?
- The process capability set
- The set of capabilties that were
actually required
- In Irix you can get privilege by
either having the capabilty or by
being root. If you got privilege
not because you have the capability
but because you're root that is
indicated as well.
- If you don't get access the capabilty
that was checked that failed is noted.
The capabilities of the process
or the capability required
to successfully make the syscall? This would likely
add a lot of text to the
message the kernel sends.
Yes, it does. On the other hand, it allows you
to identify and filter based on the capability
involved. This is very important in an LSPP
system, where it is very important to keep an
eye on MAC violations.
I would have to say we
can't do this unless there
is a certification requirement that we are trying to
meet. Even then, maybe
something that's a bitmap might be all we can do.
A bitmap would suffice, although it might not be
very convinient.
Post by Casey Schaufler
This is probably a bit late in the discussion,
but have y'all considered using a tokenized audit
record format?
Yes. The audit program has a format_type
configuration option so these can be
written. Send the patch to me or this mail list
against the latest audit
daemon code.
Hum. I'll have to see what I can do.


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



__________________________________
Do you Yahoo!?
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250
Steve Grubb
2005-01-24 16:48:30 UTC
Permalink
Post by Steve Grubb
Which capabilities?
    - The process capability set
    - The set of capabilties that were
      actually required
Both? The capabilities required should be cast in concrete and not
configurable. Not sure what value this adds other than a convenience.
    - In Irix you can get privilege by
      either having the capabilty or by
      being root. If you got privilege
      not because you have the capability
      but because you're root that is
      indicated as well.
In linux you can be root and not able to add capabilities or lose capabilities
since you gave up that capability. So, I'm not sure if this is useful in this
situation.
Post by Steve Grubb
Yes. The audit program has a format_type
configuration option so these can be
written. Send the patch to me or this mail list
against the latest audit
daemon code.
Hum. I'll have to see what I can do.
Just write a function similar to format_raw in lib/libaudit.c. Around line 199
in src/auditd-event.c is a switch statement & LF_RAW case. Just add another
case to call your formatting function. The formatting function should malloc
& write to a buffer that the caller will free later. That's all there is to
it.

-Steve
Casey Schaufler
2005-01-24 16:57:36 UTC
Permalink
Steve Grubb
2005-01-24 18:29:49 UTC
Permalink
If I have 6 capabilities but only need one
of them to perform an action the process list
does not identify the policy that is being
overridden.
Maybe this is a wording issue. In Linux, you start with capabilities and lose
them. You cannot override.
If I need 2 capabilities but only
have one, the one that I don't have but needed
needs to be pointed out.
I can see this being useful when writing software, but production systems
should have the capabilities set correctly at installation.
The capabilities required to perform an action will not
be sent in concrete. For example, accessing
/a/file may require different capabilities depending on
the mode of /a.
We are talking about posix capabilities, right? They are bound to a process
and enforced on a syscall by the kernel. That *is* cast in concrete unless
you hack the kernel sources.

-Steve
Chris Wright
2005-01-24 18:40:08 UTC
Permalink
Post by Steve Grubb
If I have 6 capabilities but only need one
of them to perform an action the process list
does not identify the policy that is being
overridden.
Maybe this is a wording issue. In Linux, you start with capabilities and lose
them. You cannot override.
Yeah, that's _mostly_ true. You have multiple sets. The effective set
is what is checked against. But the permitted set may be larger than the
effective set, in which case you could raise caps if you've momentarily
dropped one. Granted, not much of this is ever used.
Post by Steve Grubb
If I need 2 capabilities but only
have one, the one that I don't have but needed
needs to be pointed out.
I can see this being useful when writing software, but production systems
should have the capabilities set correctly at installation.
Yes, it's critical during developement and QA. Of course, you can
always get something to say directly...$pid wanted $cap. SELinux does
this now, for example. Didn't think it was needed for something like
CAPP compliant audit records though.
Post by Steve Grubb
The capabilities required to perform an action will not
be sent in concrete. For example, accessing
/a/file may require different capabilities depending on
the mode of /a.
We are talking about posix capabilities, right? They are bound to a process
and enforced on a syscall by the kernel. That *is* cast in concrete unless
you hack the kernel sources.
Well, something like chmod -w file, will make a difference. I assume
that's what Casey's getting at.

thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
Casey Schaufler
2005-01-24 19:26:11 UTC
Permalink
On Monday 24 January 2005 11:57, Casey Schaufler
If I have 6 capabilities but only need one
of them to perform an action the process list
does not identify the policy that is being
overridden.
Maybe this is a wording issue. In Linux, you start
with capabilities and lose
them. You cannot override.
A posix capability gives the process the privilege
to override a system policy. A process with
CAP_DAC_READ in its effective set can override
the system DAC policy.
If I need 2 capabilities but only
have one, the one that I don't have but needed
needs to be pointed out.
I can see this being useful when writing software,
but production systems
should have the capabilities set correctly at
installation.
If everything could be counted on to work just
right then we wouldn't need an audit trail.
The capabilities required to perform an action
will not
be sent in concrete. For example, accessing
/a/file may require different capabilities
depending on
the mode of /a.
We are talking about posix capabilities, right?
Oh my, yes.
They are bound to a process
and enforced on a syscall by the kernel. That *is*
cast in concrete unless
you hack the kernel sources.
Yes. A syscall (e.g. open) may require more
than one capability, depending on the objects
involved and their security attributes. Or they
may require none. Whatever the case, the audit
record needs to indicate which of three statements
are true:

- The action succeeded without use of privilege
- The action succeeded, but only because it had
some set of capabilities.
- The action failed, but would have succeeded
had it had some set of capabilities.

In either of the last two cases the capabilities
that were checked must be reported, at least
according to the evaluation team I dealt with.

Note that "the action failed, but not because
of the absence of capabilities" is not on the list.
This is the case that does not have to be audited.



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



__________________________________
Do you Yahoo!?
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250

Loading...