2 p.m.
Hello,
I've been kind of thinking about this. Presumably, we want to audit
both failed and successful attempts in whatever vfs function we happen
to be in. For instance, if we fall out of vfs_mkdir because
may_create returned an error, we'd like to receive an audit message
that said something like, "filename=myfile syscall= mkdir()
error=<errno>.....", but, would I want to do this by hooking each
conditional statement? Is there a better approach? The only other
one I can think of would be to have one exit point in the functions
and audit right before we exit...
i.e.:
int vfs_create(struct inode *dir, struct dentry *dentry, int mode,
struct nameidata *nd)
{
int error = may_create(dir, dentry, nd);
if (error)
goto vfs_create_exit;
if (!dir->i_op || !dir->i_op->create) {
error = -EACCES;
goto vfs_create_exit;
}
mode &= S_IALLUGO;
mode |= S_IFREG;
error = security_inode_create(dir, dentry, mode);
if (error)
goto vfs_create_exit;
DQUOT_INIT(dir);
error = dir->i_op->create(dir, dentry, mode, nd);
if (!error) {
inode_dir_notify(dir, DN_CREATE);
security_inode_post_create(dir, dentry, mode);
}
vfs_create_exit:
audit_inode_create(dir, dentry, error, mode);
return error;
}
--
- Timothy R. Chavez
2:03 p.m.
On Tue, 2004-12-14 at 15:00, Timothy R. Chavez wrote:
Hello,
I've been kind of thinking about this. Presumably, we want to audit
both failed and successful attempts in whatever vfs function we happen
to be in. For instance, if we fall out of vfs_mkdir because
may_create returned an error, we'd like to receive an audit message
that said something like, "filename=myfile syscall= mkdir()
error=<errno>.....", but, would I want to do this by hooking each
conditional statement? Is there a better approach? The only other
one I can think of would be to have one exit point in the functions
and audit right before we exit...
The audit framework already lets you audit on syscall exit, which lets
you capture information like this. As I understand it, you don't need
additional hooks for that purpose, just for enabling auditing based on
object identity and for propagating audit attributes on objects.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
2:31 p.m.
On Tue, Dec 14, 2004 at 03:03:08PM -0500, Stephen Smalley wrote:
On Tue, 2004-12-14 at 15:00, Timothy R. Chavez wrote:
> I've been kind of thinking about this. Presumably, we want to audit
> both failed and successful attempts in whatever vfs function we happen
> to be in. For instance, if we fall out of vfs_mkdir because
> may_create returned an error, we'd like to receive an audit message
> that said something like, "filename=myfile syscall= mkdir()
> error=<errno>.....", but, would I want to do this by hooking each
> conditional statement? Is there a better approach? The only other
> one I can think of would be to have one exit point in the functions
> and audit right before we exit...
The audit framework already lets you audit on syscall exit, which lets
you capture information like this. As I understand it, you don't need
additional hooks for that purpose, just for enabling auditing based on
object identity and for propagating audit attributes on objects.
Agreed, the existing LAF approach of intercepting system calls could
remain unchanged:
- system call is entered, audit intercept notes that it's of potential
interest to audit (i.e. due to filter rules being configured for
open()). Syscall arguments passed directly in registers are directly
available (i.e. SYSV SHM IDs), but the audit code does not attempt to
retrieve anything that is passed indirectly via userspace pointers.
- while system call is executing, additional information is collected
based on the data copied from userspace by the syscall. In the case of
filesystem operation, this would be the audit attribute associated with
the inode being worked on.
- when the system call is complete, the filter rules are applied to the
available data (including the additional info), and an audit record
is generated and sent to userspace.
The role of the VFS hooks is simply to ensure that objects in the
filesystem have the audit attribute set correctly even when they get
moved around and created in the filesystem. It essentially adds the
necessary logic to handle the position-based audit requirements that the
LAF inode-based approach can't do directly.
It's still open if the audit attribute is a real extended attribute
stored on disk, or if it's virtual and exists only in the audit VFS
layer. Storing them on disk makes it automatically persistent, while the
virtual approach requires the admin to keep a separate audit config list
up to date and reload it on boot.
-Klaus
2:54 p.m.
- while system call is executing, additional information is
collected
based on the data copied from userspace by the syscall. In the case of
filesystem operation, this would be the audit attribute associated with
the inode being worked on.
This might be a little insane, that is, from the current syscall
audit, to figure out "the inode being worked on." In ptrace there is
an audit_syscall_enter hook and audit_syscall_exit hook. In neither
hook is there a reasonable way to discover the inode associated with
the syscall argument. This is why I think its easiest to do the
logging in the VFS for this portion of the record, at least... At this
point, we have a dentry associated with an inode (the inode we're
interested in), to work with.
- when the system call is complete, the filter rules are applied to
the
available data (including the additional info), and an audit record
is generated and sent to userspace.
In my way, this wouldn't work to well because the syscall could be
filtered away and the VFS portion would be in userland waiting...
-Tim
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
--
- Timothy R. Chavez
3:07 p.m.
On Tue, Dec 14, 2004 at 08:54:27PM +0000, Timothy R. Chavez wrote:
> - while system call is executing, additional information is
collected
> based on the data copied from userspace by the syscall. In the case of
> filesystem operation, this would be the audit attribute associated with
> the inode being worked on.
This might be a little insane, that is, from the current syscall
audit, to figure out "the inode being worked on." In ptrace there is
an audit_syscall_enter hook and audit_syscall_exit hook. In neither
hook is there a reasonable way to discover the inode associated with
the syscall argument. This is why I think its easiest to do the
logging in the VFS for this portion of the record, at least... At this
point, we have a dentry associated with an inode (the inode we're
interested in), to work with.
But the existing audit code already does this, look at audit_getname()
and audit_inode() in kernel/auditsc.c, which get called from
fs/namei.c:getname() and fs/namei.c:path_lookup() respectively.
The VFS code knows all about the inode, and the audit context is
available in the current process context.
> - when the system call is complete, the filter rules are applied
to the
> available data (including the additional info), and an audit record
> is generated and sent to userspace.
In my way, this wouldn't work to well because the syscall could be
filtered away and the VFS portion would be in userland waiting...
But that's insane from a filtering point of view ;-)
If you tell audit to only make records for operations on certain files,
you don't want syscall entry and intermediate records being sent to
userspace for all open() operations where the necessary data wasn't
available yet. I think that implies that you need to first collect data
in the kernel until you know if userspace will be interested.
Sending multiple partial audit records for every syscall to userspace and
then having auditd do all the filtering would most likely have pathetic
performance.
-Klaus
4:29 p.m.
On Tue, 2004-12-14 at 14:31 -0600, Klaus Weidner wrote:
It's still open if the audit attribute is a real extended
attribute
stored on disk, or if it's virtual and exists only in the audit VFS
layer. Storing them on disk makes it automatically persistent, while the
virtual approach requires the admin to keep a separate audit config list
up to date and reload it on boot.
There are advantages and disadvantages to both approaches.
If you store audit attributes as a real file-system attribute:
* You're unlikely to be able to audit files on non-native filesystems
(eg: VFAT, CDROM, or USBKeys) - one audit objective that is very popular
in intelligence circles, for example, is "What has been copied out to
removable media?"
* Audit object inheritance can become VERY complex:
- When a new file is created in an audited directory, we have to ensure
that the parent directories audit attributes are applied immediately,
and the actual 'create/open' audit events associated with the created
file are also retrospectively created. (Windows NT had real problems
with this. Windows 2000 seems to have come up with something relatively
reasonable).
* Wildcard matching of file accesses becomes pretty-much impossible.
- A sample objective might be "Tell me whenever someone accesses a file
within a directory called 'SECRET_FILES'"
* On the positive side, your CPU usage is likely to be significantly
less, as the audit layer just needs to check for an 'auditing enabled'
flag before deciding whether to exit, or continue processing.
If you retain a 'virtual' attribute within the audit subsystem:
* Your CPU usage increases, as you have to go through the full inode ->
real path chain to form a full directory path, before comparing the
directory path against the user's filters. (eg: "Tell me whenever
someone writes a file to /media/usbkey/.*")
* You can do wildcard (or regular expression) matching on target files,
which is VERY useful.
* File system type is pretty-much irrelevant.
* Object inheritance in the file system is not a concern.
Summary of operating system implementations:
Windows NT / 2000 / XP / 2003: On-file-system attribute.
Solaris / AIX / Irix / Snare: Virtual.
Regards,
Leigh.
--
Leigh Purdie, Director - InterSect Alliance Pty Ltd
http://www.intersectalliance.com/
4:44 p.m.
I think its reasonable enough to keep it virtual. The added benefit
to doing it this way is we no longer need the mapnode data structure.
We assume that all files and directories to be audited complete paths
that already exist in the file system. Because we're storing
information on the parent node, the file or directory to be audited
does not have to exist, but when it does exist, it will get audited.
If the parent directory is destroyed and then recreated, there's no
way to for it to regain knowledge of what its suppose to be watching
or if its on the path to something that needs to be watched. There
are disadvantages to not supporting this, but for simplicities sake,
someone could simply restart auditd or whatever to remap the changes.
Perhaps the mapnode tree (which basically lays out a "theoretical"
flat file system tree in memory and maps into inodes that represent
each position in that tree) would be a nice feature to add, but is not
completely necessary at this point, to achieve the functionality we'd
like. It might be really hard to push and could slow down progress
towards an upstream solution.
On Wed, 15 Dec 2004 09:29:05 +1100, Leigh Purdie
<Leigh.Purdie(a)intersectalliance.com> wrote:
On Tue, 2004-12-14 at 14:31 -0600, Klaus Weidner wrote:
> It's still open if the audit attribute is a real extended attribute
> stored on disk, or if it's virtual and exists only in the audit VFS
> layer. Storing them on disk makes it automatically persistent, while the
> virtual approach requires the admin to keep a separate audit config list
> up to date and reload it on boot.
There are advantages and disadvantages to both approaches.
If you store audit attributes as a real file-system attribute:
* You're unlikely to be able to audit files on non-native filesystems
(eg: VFAT, CDROM, or USBKeys) - one audit objective that is very popular
in intelligence circles, for example, is "What has been copied out to
removable media?"
* Audit object inheritance can become VERY complex:
- When a new file is created in an audited directory, we have to ensure
that the parent directories audit attributes are applied immediately,
and the actual 'create/open' audit events associated with the created
file are also retrospectively created. (Windows NT had real problems
with this. Windows 2000 seems to have come up with something relatively
reasonable).
* Wildcard matching of file accesses becomes pretty-much impossible.
- A sample objective might be "Tell me whenever someone accesses a file
within a directory called 'SECRET_FILES'"
* On the positive side, your CPU usage is likely to be significantly
less, as the audit layer just needs to check for an 'auditing enabled'
flag before deciding whether to exit, or continue processing.
If you retain a 'virtual' attribute within the audit subsystem:
* Your CPU usage increases, as you have to go through the full inode ->
real path chain to form a full directory path, before comparing the
directory path against the user's filters. (eg: "Tell me whenever
someone writes a file to /media/usbkey/.*")
* You can do wildcard (or regular expression) matching on target files,
which is VERY useful.
* File system type is pretty-much irrelevant.
* Object inheritance in the file system is not a concern.
Summary of operating system implementations:
Windows NT / 2000 / XP / 2003: On-file-system attribute.
Solaris / AIX / Irix / Snare: Virtual.
Regards,
Leigh.
--
Leigh Purdie, Director - InterSect Alliance Pty Ltd
http://www.intersectalliance.com/
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
--
- Timothy R. Chavez
4:49 p.m.
* Timothy R. Chavez (chavezt(a)gmail.com) wrote:
I think its reasonable enough to keep it virtual. The added benefit
to doing it this way is we no longer need the mapnode data structure.
We assume that all files and directories to be audited complete paths
that already exist in the file system. Because we're storing
information on the parent node, the file or directory to be audited
does not have to exist, but when it does exist, it will get audited.
If the parent directory is destroyed and then recreated, there's no
way to for it to regain knowledge of what its suppose to be watching
or if its on the path to something that needs to be watched. There
are disadvantages to not supporting this, but for simplicities sake,
someone could simply restart auditd or whatever to remap the changes.
Each process has a namespace (potentially private). So /etc/sensitive
may not be the same file in each namespace.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
4:57 p.m.
On Tue, 2004-12-14 at 22:44 +0000, Timothy R. Chavez wrote:
Because we're storing
information on the parent node, the file or directory to be audited
does not have to exist, but when it does exist, it will get audited.
*VERY* Good point.
A good example of this sort of thing might be an objective that says:
"Tell me whenever someone attempts to write to /etc/hosts.equiv".
There may not be an actual /etc/hosts.equiv on your file system, but the
system administrator will definitely want to know if someone attempts to
create that file.
Perhaps the mapnode tree (which basically lays out a
"theoretical"
flat file system tree in memory and maps into inodes that represent
each position in that tree) would be a nice feature to add, but is not
completely necessary at this point, to achieve the functionality we'd
like. It might be really hard to push and could slow down progress
towards an upstream solution.
Agree. If we can find a nice low-CPU cost way of converting an Inode to
a path, and filtering on that basis, it would be very handy.
In snare, we do this by either:
* Grabbing the path of the inode (if available), or
* Saving off the path provided to the system call (eg: ../../blah), plus
the current process vfsroot (eg: /etc/security).
We send both these paths to userspace, and do a custom realpath() on
them (/blah). Not an ideal solution, but a minimally invasive one for
the kernel. It also means that all path filtering has to be done in
userspace, which means a lot of (potentially unnecessary) kernel-
userspace comms.
L.
--
Leigh Purdie, Director - InterSect Alliance Pty Ltd
http://www.intersectalliance.com/
4:58 p.m.
On Wed, Dec 15, 2004 at 09:29:05AM +1100, Leigh Purdie wrote:
If you store audit attributes as a real file-system attribute:
* You're unlikely to be able to audit files on non-native filesystems
(eg: VFAT, CDROM, or USBKeys) - one audit objective that is very popular
in intelligence circles, for example, is "What has been copied out to
removable media?"
Note that it would be fairly easy to do all-or-nothing audit for
non-native filesystems based on the properties of the mount point or
filesystem type, so the removable media example is not necessarily a
problem if treated as a special case.
If you retain a 'virtual' attribute within the audit
subsystem:
* Your CPU usage increases, as you have to go through the full inode ->
real path chain to form a full directory path, before comparing the
directory path against the user's filters. (eg: "Tell me whenever
someone writes a file to /media/usbkey/.*")
Your suggestion is based on the audit system storing paths as the virtual
attributes, and using these for comparisons. The LAuS (SuSE) audit system
works roughly this way, using a prefix() predicate on (canonicalized)
path name arguments.
One approach we had also been discussing had been to attach the
properties to in-memory dentry or inode objects for individual files and
directores, in essence an in-memory overlay of additional attributes over
the existing file tree. This is of course only feasible if the number of
objects with individual audit attributes is small enough to not use too
much memory. That would have runtime characteristics similar to the real
filesystem attributes, and would also not necessarily offer the
flexibility of the path-based one you mention. I think that the consensus
was that this appears to be too complex compared to the simple filesystem
extended attributes.
-Klaus
5:17 p.m.
On Tue, 2004-12-14 at 16:58 -0600, Klaus Weidner wrote:
On Wed, Dec 15, 2004 at 09:29:05AM +1100, Leigh Purdie wrote:
> If you store audit attributes as a real file-system attribute:
> * You're unlikely to be able to audit files on non-native filesystems
> (eg: VFAT, CDROM, or USBKeys) - one audit objective that is very popular
> in intelligence circles, for example, is "What has been copied out to
> removable media?"
Note that it would be fairly easy to do all-or-nothing audit for
non-native filesystems based on the properties of the mount point or
filesystem type, so the removable media example is not necessarily a
problem if treated as a special case.
Good point. I have come across instances though, where it is important
to monitor non-native file systems. All-or-nothing works up to a point,
but falls over when the volume of file accesses is very large.
An example might be where a solaris box acts as a SAN/NAS, mounted over
NFS - but the users wants to make use of the linux audit subsystem to
monitor a subset of that file system.
Two options:
* Auditing is the responsibility of the host operating system (ie: Let
sun take care of it), or
* There needs to be some way of flagging only some files for audit
analysis.
I'm not sure I advocate either approach at this point.. but it certainly
factors into the decision for/against on-file-system attributes. :)
> If you retain a 'virtual' attribute within the audit
subsystem:
> * Your CPU usage increases, as you have to go through the full inode ->
> real path chain to form a full directory path, before comparing the
> directory path against the user's filters. (eg: "Tell me whenever
> someone writes a file to /media/usbkey/.*")
Your suggestion is based on the audit system storing paths as the virtual
attributes, and using these for comparisons.
True.
One approach we had also been discussing had been to attach the
properties to in-memory dentry or inode objects for individual files and
directores, in essence an in-memory overlay of additional attributes over
the existing file tree. This is of course only feasible if the number of
objects with individual audit attributes is small enough to not use too
much memory.
True. This might actually be very appropriate for a simple 'tell me
stuff that has changed in /etc' sort-of-configuration, which would be
fine for quite a few sites.
The more complex: "Audit every file in /data, and tell me whether the
user X,Y, or Z access any file successfully with a directory path
containing the word 'SECRETSTUFF'", might be a bit more challenging to
implement, particularly if there are hundreds and thousands of files in
such directories. (This is a real-world example/requirement by the way..
with a few details changed, obviously :)
The kernel/userspace split on that objective might be along the lines
of:
kernel: Audit all files in /data for READ or WRITE, success.
userspace: check if filename contains "/SECRETSTUFF/", and is accessed
by user X, Y or Z.
L.
2:44 p.m.
Stephen,
Yes I've also been giving that some thought too. How we split up
responsibility. If we do as you suggested, we'd simply have to piece
together each log message in userspace with the appropriate timestamp
and serial number to get the full record. Still there would need to
be a hook there that gave the piece of the record the syscall couldn't
create, that is, the "filename=%s filterkey=%s (which could be used in
userspace to index a table that will return the full path location
that filename completes or whatever)", right? Plus the hooks to
assign "auditability" to those filenames that appear in our
watchlists. Anyway, this approach is reasonable. I'll just figure
out this route and leave it up to userspace to stich the complete
record together.
(send this privately by accident)
On Tue, 14 Dec 2004 15:03:08 -0500, Stephen Smalley <sds(a)epoch.ncsc.mil> wrote:
On Tue, 2004-12-14 at 15:00, Timothy R. Chavez wrote:
> Hello,
>
> I've been kind of thinking about this. Presumably, we want to audit
> both failed and successful attempts in whatever vfs function we happen
> to be in. For instance, if we fall out of vfs_mkdir because
> may_create returned an error, we'd like to receive an audit message
> that said something like, "filename=myfile syscall= mkdir()
> error=<errno>.....", but, would I want to do this by hooking each
> conditional statement? Is there a better approach? The only other
> one I can think of would be to have one exit point in the functions
> and audit right before we exit...
The audit framework already lets you audit on syscall exit, which lets
you capture information like this. As I understand it, you don't need
additional hooks for that purpose, just for enabling auditing based on
object identity and for propagating audit attributes on objects.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
--
- Timothy R. Chavez
2:48 p.m.
On Tue, 2004-12-14 at 15:44, Timothy R. Chavez wrote:
Yes I've also been giving that some thought too. How we split
up
responsibility. If we do as you suggested, we'd simply have to piece
together each log message in userspace with the appropriate timestamp
and serial number to get the full record.
That is how the audit framework was designed and intended to be used,
and how it is used by SELinux presently (e.g. SELinux hook generates an
audit message, and then another one is generated at syscall exit if
we've enabled syscall auditing).
Still there would need to
be a hook there that gave the piece of the record the syscall couldn't
create, that is, the "filename=%s filterkey=%s (which could be used in
userspace to index a table that will return the full path location
that filename completes or whatever)", right?
filename (to the extent it has been copied by the kernel) is already
provided at syscall exit. You do want a hook, but it can occur very
early in the function (possibly even in a common helper like permission
that is called by everyone), and it just needs to call audit_log* with
any information not available at syscall exit, like the object identity
/ attribute, device and inode number, etc. Alternative would be to save
that state in the audit context from your hook function and extract it
in audit_log_exit() as part of the syscall exit processing, but then
youhave multi-component issues, e.g. audit may be triggered on multiple
components in a single pathname on a single syscall, so it is easier to
decompose via multiple audit_log* calls and let userspace piece it back
together based on the (timestamp,serial) tuples.
Plus the hooks to
assign "auditability" to those filenames that appear in our
watchlists. Anyway, this approach is reasonable. I'll just figure
out this route and leave it up to userspace to stich the complete
record together.
Yes. And that is the hardest part to get right, particularly in a race
free way. Look at the d_instantiate/d_splice_alias security hooks;
post_create isn't sufficient. And even the d_instantiate/d_splice_alias
hooks might not be sufficient (based on a recent bug report where an
inode is reaching inode_has_perm before it has completed inode security
initialization).
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
2:50 p.m.
Tim,
Why can't you store the info in the current->audit record until syscall
exit, and only send a message to userspace if the syscall exit says to
do so?
-serge
Quoting Timothy R. Chavez (chavezt(a)gmail.com):
Stephen,
Yes I've also been giving that some thought too. How we split up
responsibility. If we do as you suggested, we'd simply have to piece
together each log message in userspace with the appropriate timestamp
and serial number to get the full record. Still there would need to
be a hook there that gave the piece of the record the syscall couldn't
create, that is, the "filename=%s filterkey=%s (which could be used in
userspace to index a table that will return the full path location
that filename completes or whatever)", right? Plus the hooks to
assign "auditability" to those filenames that appear in our
watchlists. Anyway, this approach is reasonable. I'll just figure
out this route and leave it up to userspace to stich the complete
record together.
(send this privately by accident)
On Tue, 14 Dec 2004 15:03:08 -0500, Stephen Smalley <sds(a)epoch.ncsc.mil> wrote:
> On Tue, 2004-12-14 at 15:00, Timothy R. Chavez wrote:
> > Hello,
> >
> > I've been kind of thinking about this. Presumably, we want to audit
> > both failed and successful attempts in whatever vfs function we happen
> > to be in. For instance, if we fall out of vfs_mkdir because
> > may_create returned an error, we'd like to receive an audit message
> > that said something like, "filename=myfile syscall= mkdir()
> > error=<errno>.....", but, would I want to do this by hooking each
> > conditional statement? Is there a better approach? The only other
> > one I can think of would be to have one exit point in the functions
> > and audit right before we exit...
>
> The audit framework already lets you audit on syscall exit, which lets
> you capture information like this. As I understand it, you don't need
> additional hooks for that purpose, just for enabling auditing based on
> object identity and for propagating audit attributes on objects.
>
> --
> Stephen Smalley <sds(a)epoch.ncsc.mil>
> National Security Agency
>
>
--
- Timothy R. Chavez
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
2:53 p.m.
On Tue, 2004-12-14 at 15:50, Serge E. Hallyn wrote:
Why can't you store the info in the current->audit record
until syscall
exit, and only send a message to userspace if the syscall exit says to
do so?
A single syscall might trigger auditing on multiple objects, e.g.
multi-component pathname lookup where multiple components are flagged
for auditing. The audit framework was designed to allow immediate
generation of partial audit records during syscall processing that would
then enable generation of a final audit record at syscall exit, with the
ability to tie them all together via the (timestamp, serial) tuples in
userspace. That is how SELinux works with the audit subsystem; SELinux
immediately generates an audit message as appropriate from its hooks,
and this triggers generation of a final audit record for the syscall
upon exit, so you might have multiple SELinux audit messages followed by
the syscall exit one.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
2:59 p.m.
Serge,
Ok, this sounds most reasonable. Thanks
-Tim
On Tue, 14 Dec 2004 14:50:14 -0600, Serge E. Hallyn <serue(a)us.ibm.com> wrote:
Tim,
Why can't you store the info in the current->audit record until syscall
exit, and only send a message to userspace if the syscall exit says to
do so?
-serge
Quoting Timothy R. Chavez (chavezt(a)gmail.com):
> Stephen,
>
> Yes I've also been giving that some thought too. How we split up
> responsibility. If we do as you suggested, we'd simply have to piece
> together each log message in userspace with the appropriate timestamp
> and serial number to get the full record. Still there would need to
> be a hook there that gave the piece of the record the syscall couldn't
> create, that is, the "filename=%s filterkey=%s (which could be used in
> userspace to index a table that will return the full path location
> that filename completes or whatever)", right? Plus the hooks to
> assign "auditability" to those filenames that appear in our
> watchlists. Anyway, this approach is reasonable. I'll just figure
> out this route and leave it up to userspace to stich the complete
> record together.
>
> (send this privately by accident)
>
> On Tue, 14 Dec 2004 15:03:08 -0500, Stephen Smalley <sds(a)epoch.ncsc.mil>
wrote:
> > On Tue, 2004-12-14 at 15:00, Timothy R. Chavez wrote:
> > > Hello,
> > >
> > > I've been kind of thinking about this. Presumably, we want to audit
> > > both failed and successful attempts in whatever vfs function we happen
> > > to be in. For instance, if we fall out of vfs_mkdir because
> > > may_create returned an error, we'd like to receive an audit message
> > > that said something like, "filename=myfile syscall= mkdir()
> > > error=<errno>.....", but, would I want to do this by hooking
each
> > > conditional statement? Is there a better approach? The only other
> > > one I can think of would be to have one exit point in the functions
> > > and audit right before we exit...
> >
> > The audit framework already lets you audit on syscall exit, which lets
> > you capture information like this. As I understand it, you don't need
> > additional hooks for that purpose, just for enabling auditing based on
> > object identity and for propagating audit attributes on objects.
> >
> > --
> > Stephen Smalley <sds(a)epoch.ncsc.mil>
> > National Security Agency
> >
> >
>
>
> --
> - Timothy R. Chavez
>
> --
> Linux-audit mailing list
> Linux-audit(a)redhat.com
> http://www.redhat.com/mailman/listinfo/linux-audit
>
--
- Timothy R. Chavez
2:59 p.m.
On Tue, 2004-12-14 at 15:59, Timothy R. Chavez wrote:
Ok, this sounds most reasonable. Thanks
What about the situation where multiple auditable objects are involved
in the syscall, whether via multi-component pathnames, multiple pathname
arguments to the syscall (e.g. rename, link), etc? Easier to just
immediately generate the object information from your hook, and then tie
all such object-based audit records to the associated syscall exit
record via the (timestamp, serial) tuples.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
3:07 p.m.
* Stephen Smalley (sds(a)epoch.ncsc.mil) wrote:
On Tue, 2004-12-14 at 15:59, Timothy R. Chavez wrote:
> Ok, this sounds most reasonable. Thanks
What about the situation where multiple auditable objects are involved
in the syscall, whether via multi-component pathnames, multiple pathname
arguments to the syscall (e.g. rename, link), etc? Easier to just
immediately generate the object information from your hook, and then tie
all such object-based audit records to the associated syscall exit
record via the (timestamp, serial) tuples.
Or let any of those auditable objects trigger a flush on exit.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
3:09 p.m.
Yes,
But you have the problem of incomplete logs. For testing purposes the
audit log should contain coherent and complete records only. What
about just adding a list_head to the audit_context and we can just add
all the necessary information about each object to that list then just
write-out on syscall exit?
On Tue, 14 Dec 2004 15:59:13 -0500, Stephen Smalley <sds(a)epoch.ncsc.mil> wrote:
On Tue, 2004-12-14 at 15:59, Timothy R. Chavez wrote:
> Ok, this sounds most reasonable. Thanks
What about the situation where multiple auditable objects are involved
in the syscall, whether via multi-component pathnames, multiple pathname
arguments to the syscall (e.g. rename, link), etc? Easier to just
immediately generate the object information from your hook, and then tie
all such object-based audit records to the associated syscall exit
record via the (timestamp, serial) tuples.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
--
- Timothy R. Chavez
3:12 p.m.
On Tue, 2004-12-14 at 16:09, Timothy R. Chavez wrote:
Yes,
But you have the problem of incomplete logs. For testing purposes the
audit log should contain coherent and complete records only. What
about just adding a list_head to the audit_context and we can just add
all the necessary information about each object to that list then just
write-out on syscall exit?
As soon as you know that the object is auditable, you presumably would
like to have an audit record about it, even if the full operation
doesn't complete (in fact, if you've determined that the object is
auditable, you want to immediately verify that you can at least audit
that information; otherwise, you may need to take some emergency action
then, not after the operation has completed and it is too late). Note
that your hook functions are what is determining whether or not an audit
record should be generated (based on the object information).
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
3:24 p.m.
Quoting Stephen Smalley (sds(a)epoch.ncsc.mil):
On Tue, 2004-12-14 at 16:09, Timothy R. Chavez wrote:
> Yes,
>
> But you have the problem of incomplete logs. For testing purposes the
> audit log should contain coherent and complete records only. What
> about just adding a list_head to the audit_context and we can just add
> all the necessary information about each object to that list then just
> write-out on syscall exit?
As soon as you know that the object is auditable, you presumably would
like to have an audit record about it, even if the full operation
doesn't complete (in fact, if you've determined that the object is
auditable, you want to immediately verify that you can at least audit
that information; otherwise, you may need to take some emergency action
then, not after the operation has completed and it is too late). Note
that your hook functions are what is determining whether or not an audit
record should be generated (based on the object information).
Actually that's the problem - the hook functions only determine whether
the action is potentially auditable. It might only be auditable when
accessed by a certain user. Or, there might be a single user for whom
we want to audit every access. But that doesn't mean we want every access
by every user causing a partial audit record to be emitted.
Please let me know if I'm thinking wrongly...
-serge
3:22 p.m.
On Tue, 2004-12-14 at 16:24, Serge E. Hallyn wrote:
Actually that's the problem - the hook functions only determine
whether
the action is potentially auditable. It might only be auditable when
accessed by a certain user. Or, there might be a single user for whom
we want to audit every access. But that doesn't mean we want every access
by every user causing a partial audit record to be emitted.
Yes, but why can't you make the full determination in your hook
function? At the point of the hook function, you know:
- the current process information,
- the object information,
- the call site.
It is possible that you have some complex audit configuration in mind
that requires tying together information from multiple hooks in order to
determine whether or not to audit the operation, but I'm not sure
whether that is necessary.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
3:33 p.m.
On Tue, 14 Dec 2004 16:22:59 -0500, Stephen Smalley <sds(a)epoch.ncsc.mil> wrote:
On Tue, 2004-12-14 at 16:24, Serge E. Hallyn wrote:
> Actually that's the problem - the hook functions only determine whether
> the action is potentially auditable. It might only be auditable when
> accessed by a certain user. Or, there might be a single user for whom
> we want to audit every access. But that doesn't mean we want every access
> by every user causing a partial audit record to be emitted.
Yes, but why can't you make the full determination in your hook
function? At the point of the hook function, you know:
- the current process information,
- the object information,
- the call site.
Well my original message I think was hinting at doing it this way?
But to do it effectively with only one hook, you'd need one exit
point, right? If you wanted to generate a complete record as soon as
you have it ready (from the VFS function) then you'd write out to the
log a one-off message from VFS... but that will completely seperate
you from syscall filtering/auditing and change the topology of VFS
and... well, I value my life ;-).
It is possible that you have some complex audit configuration in mind
that requires tying together information from multiple hooks in order to
determine whether or not to audit the operation, but I'm not sure
whether that is necessary.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
--
- Timothy R. Chavez
3:32 p.m.
On Tue, 2004-12-14 at 16:33, Timothy R. Chavez wrote:
Well my original message I think was hinting at doing it this way?
But to do it effectively with only one hook, you'd need one exit
point, right?
No. You just need to:
1) have your hook function decide whether auditing is required,
2) if so, have it emit a partial audit record with information not
available at syscall exit,
3) this will automatically enable auditing upon syscall exit
And your audit hook can be called very early, as soon as you have the
object available.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
3:42 p.m.
Quoting Stephen Smalley (sds(a)epoch.ncsc.mil):
On Tue, 2004-12-14 at 16:24, Serge E. Hallyn wrote:
> Actually that's the problem - the hook functions only determine whether
> the action is potentially auditable. It might only be auditable when
> accessed by a certain user. Or, there might be a single user for whom
> we want to audit every access. But that doesn't mean we want every access
> by every user causing a partial audit record to be emitted.
Yes, but why can't you make the full determination in your hook
function? At the point of the hook function, you know:
- the current process information,
- the object information,
- the call site.
Good point.
It is possible that you have some complex audit configuration in
mind
that requires tying together information from multiple hooks in order to
determine whether or not to audit the operation, but I'm not sure
whether that is necessary.
No, I think we all agree that anything much more complicated should be done
in userspace. The only real reason to care about doing some in kernel space,
I think, is to minimize wasted kernel->auditd traffic.
-serge
4:47 p.m.
On Tue, 2004-12-14 at 15:42 -0600, Serge E. Hallyn wrote:
No, I think we all agree that anything much more complicated should
be done
in userspace. The only real reason to care about doing some in kernel space,
I think, is to minimize wasted kernel->auditd traffic.
Caveat: I don't recommend asking userspace to grab the full path name
from inode information supplied by the kernel, as has been suggested in
the past. Although this shifts the burden of processing in the right
direction (ie: to user-space), by the time the inode info gets there,
the file might have already gone.
UID/GID -> User/Group Name has similar issues I guess, but much harder
to cover (as the kernel generally doesn't have visibility of user
names).
Leigh.
--
Leigh Purdie, Director - InterSect Alliance Pty Ltd
http://www.intersectalliance.com/
5:04 p.m.
On Wed, Dec 15, 2004 at 09:47:38AM +1100, Leigh Purdie wrote:
On Tue, 2004-12-14 at 15:42 -0600, Serge E. Hallyn wrote:
> No, I think we all agree that anything much more complicated should be done
> in userspace. The only real reason to care about doing some in kernel space,
> I think, is to minimize wasted kernel->auditd traffic.
Caveat: I don't recommend asking userspace to grab the full path name
from inode information supplied by the kernel, as has been suggested in
the past. Although this shifts the burden of processing in the right
direction (ie: to user-space), by the time the inode info gets there,
the file might have already gone.
Agreed, none of the current approaches are planning to do that.
UID/GID -> User/Group Name has similar issues I guess, but much
harder
to cover (as the kernel generally doesn't have visibility of user
names).
Well, at least here the mapping can be changed only by trusted processes,
so this doesn't seem exploitable. Since CAPP requires changes to the user
database to be audited, the information to reconstruct the correct
meaning would be present in audit records.
-Klaus
10:01 a.m.
On Tue, 2004-12-14 at 16:22, Stephen Smalley wrote:
Yes, but why can't you make the full determination in your hook
function? At the point of the hook function, you know:
- the current process information,
- the object information,
- the call site.
It is possible that you have some complex audit configuration in mind
that requires tying together information from multiple hooks in order to
determine whether or not to audit the operation, but I'm not sure
whether that is necessary.
On the other hand, it may be that by simply saving the object identity
information on a list in the current audit_context and deferring
determination to the syscall exit code, you can reduce the number of
audit hooks within the VFS, e.g. just hook permission(9) rather than the
individual vfs_* functions.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
11:03 a.m.
On Wed, 15 Dec 2004 11:01:49 -0500, Stephen Smalley <sds(a)epoch.ncsc.mil> wrote:
On Tue, 2004-12-14 at 16:22, Stephen Smalley wrote:
> Yes, but why can't you make the full determination in your hook
> function? At the point of the hook function, you know:
> - the current process information,
> - the object information,
> - the call site.
>
> It is possible that you have some complex audit configuration in mind
> that requires tying together information from multiple hooks in order to
> determine whether or not to audit the operation, but I'm not sure
> whether that is necessary.
On the other hand, it may be that by simply saving the object identity
information on a list in the current audit_context and deferring
determination to the syscall exit code, you can reduce the number of
audit hooks within the VFS, e.g. just hook permission(9) rather than the
individual vfs_* functions.
That seems like a pretty good idea since all the information about the
syscall will be covered else where, all we really need is a place
where we have the inode and access to its audit data. The two places
(maybe three? vfs_mknod?) vfs_create and vfs_mkdir (vfs_link wouldn't
be necessary if we assume a hardlink's inode audit information is
never overwritten ever)
What this means is we can add some additional (minimal) filtering
rules to the kernel for our file system objects.
Are there any objections with this approach?
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
--
- Timothy R. Chavez
11:13 a.m.
hm "never overwritten ever" :-) all this holiday cheer is having
adverse effects on me.
On Wed, 15 Dec 2004 17:03:35 +0000, Timothy R. Chavez <chavezt(a)gmail.com> wrote:
On Wed, 15 Dec 2004 11:01:49 -0500, Stephen Smalley
<sds(a)epoch.ncsc.mil> wrote:
> On Tue, 2004-12-14 at 16:22, Stephen Smalley wrote:
> > Yes, but why can't you make the full determination in your hook
> > function? At the point of the hook function, you know:
> > - the current process information,
> > - the object information,
> > - the call site.
> >
> > It is possible that you have some complex audit configuration in mind
> > that requires tying together information from multiple hooks in order to
> > determine whether or not to audit the operation, but I'm not sure
> > whether that is necessary.
>
> On the other hand, it may be that by simply saving the object identity
> information on a list in the current audit_context and deferring
> determination to the syscall exit code, you can reduce the number of
> audit hooks within the VFS, e.g. just hook permission(9) rather than the
> individual vfs_* functions.
That seems like a pretty good idea since all the information about the
syscall will be covered else where, all we really need is a place
where we have the inode and access to its audit data. The two places
(maybe three? vfs_mknod?) vfs_create and vfs_mkdir (vfs_link wouldn't
be necessary if we assume a hardlink's inode audit information is
never overwritten ever)
What this means is we can add some additional (minimal) filtering
rules to the kernel for our file system objects.
Are there any objections with this approach?
>
> --
> Stephen Smalley <sds(a)epoch.ncsc.mil>
> National Security Agency
>
> --
> Linux-audit mailing list
> Linux-audit(a)redhat.com
> http://www.redhat.com/mailman/listinfo/linux-audit
>
--
- Timothy R. Chavez
--
- Timothy R. Chavez
11:15 a.m.
On Wed, 2004-12-15 at 12:03, Timothy R. Chavez wrote:
That seems like a pretty good idea since all the information about
the
syscall will be covered else where, all we really need is a place
where we have the inode and access to its audit data. The two places
(maybe three? vfs_mknod?) vfs_create and vfs_mkdir (vfs_link wouldn't
be necessary if we assume a hardlink's inode audit information is
never overwritten ever)
Do you mean hooks for preserving audit attributes? Yes, you would still
need hooks for that purpose, but for simply enabling auditing based on
object identity, a single hook in permission may be sufficient, where
that hook would check whether the object was auditable and if so, add
the object identity and requested permission mask to a list hung off of
curent->audit_context for later processing by audit_syscall_exit (in
determining whether or not to audit) and audit_log_exit (in providing
supplementary audit information in the audit record).
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
2:45 p.m.
On Wed, 2004-12-15 at 17:03 +0000, Timothy R. Chavez wrote:
> .. just hook permission(9) rather than the individual vfs_*
functions.
That seems like a pretty good idea since all the information about the
syscall will be covered else where, all we really need is a place
where we have the inode and access to its audit data.
Are there any objections with this approach?
Does this approach still allow us to cover the example of failed file-
opens (no such file or dir), where an inode does not exist, but the
administrator wants an indication that the attempt was made?
eg: normal user$ echo "+ + someuser" > /etc/hosts.equiv
bash: /etc/hosts.equiv: No such file or directory
In general, two (or more) audit events could be generated here:
* Permission denied on create file, in /etc (which would be covered by
the permission() inode), and
* User attempted to WRITE to /etc/hosts.equiv, and failed.
Leigh.
--
Leigh Purdie, Director - InterSect Alliance Pty Ltd
http://www.intersectalliance.com/
3:14 p.m.
On Thu, Dec 16, 2004 at 07:45:00AM +1100, Leigh Purdie wrote:
Does this approach still allow us to cover the example of failed
file-
opens (no such file or dir), where an inode does not exist, but the
administrator wants an indication that the attempt was made?
eg: normal user$ echo "+ + someuser" > /etc/hosts.equiv
bash: /etc/hosts.equiv: No such file or directory
In general, two (or more) audit events could be generated here:
* Permission denied on create file, in /etc (which would be covered by
the permission() inode), and
* User attempted to WRITE to /etc/hosts.equiv, and failed.
Note that what you're asking for goes beyond literal CAPP requirements:
5.2.2 FDP_ACF.1
Event: All requests to perform an operation on an object covered by the SFP
Details: The identity of the object.
("Details" are in addition to the required "Date and time of the event,
type of event, subject identity, and the outcome (success or failure) of
the event")
A file that doesn't exist is not an object and it can't have an operation
performed on it. The admin could always create an empty file as a
placeholder for an unused trusted database (which /etc/hosts.equiv isn't
for the planned RHEL ST) to get write attempts audited anyway.
You could also consider the file creation as an operation on the
*directory* and get it audited that way, meaning that an admin should
specify audit rules for the directory to be informed about failed
attempts to create new files.
-Klaus
3:37 p.m.
> eg: normal user$ echo "+ + someuser" >
/etc/hosts.equiv
> bash: /etc/hosts.equiv: No such file or directory
>
> In general, two (or more) audit events could be generated here:
> * Permission denied on create file, in /etc (which would be covered by
> the permission() inode), and
> * User attempted to WRITE to /etc/hosts.equiv, and failed.
Note that what you're asking for goes beyond literal CAPP requirements:
Unfortunately, there are many examples of where CAPP requirements, and
real-world-usage significantly differ. :)
I suspect this is more of a political discussion than something that
deserves to be in a feature-set analysis ;) .. but since the two
slightly overlap; based on over 10 years of working with audit
subsystems on many OS's, in many agencies, I'm just trying to bring a
summary of the key customer requirements that we've seen over time to
the discussion.
By all means, have a goal of meeting C2/CAPP requirements - it's very
important to have on the checklist for federal government (and other
sectors) acceptance (and looks good on the marketing stuff too). Just
keep an open mind w.r.t things that CAPP doesn't cover, and try not to
cripple your design too much to meet the more 'practically inefficient'
requirements of CAPP. Otherwise, we'll end up with a technically
brilliant, but practically unworkable, audit subsystem for Linux.
The CAPP evaluation guys are pretty flexible - don't think of the CAPP
requirements as carved in stone. They work on a strategy of risk
management these days, rather than risk avoidance - so if you can
provide adequate justification why a particular feature was not
implemented quite the way they anticipated, it should not be a barrier
to accreditation.
However, I do take your point on creating a file, to audit the file. I
should probably mention though, that both Solaris, and AIX (and also
Irix, from memory), are capable of auditing 'non existent' files - so if
we were aiming for a best-of-breed implementation, it might be a
capability that we want to investigate.
Hope this contributes something to the mix. :)
L.
--
Leigh Purdie, Director - InterSect Alliance Pty Ltd
http://www.intersectalliance.com/
4:03 p.m.
On Thu, Dec 16, 2004 at 08:37:54AM +1100, Leigh Purdie wrote:
Unfortunately, there are many examples of where CAPP requirements,
and
real-world-usage significantly differ. :)
I suspect this is more of a political discussion than something that
deserves to be in a feature-set analysis ;) .. but since the two
slightly overlap; based on over 10 years of working with audit
subsystems on many OS's, in many agencies, I'm just trying to bring a
summary of the key customer requirements that we've seen over time to
the discussion.
Your input is very valuable to this, and I agree that the goal should be
to have something generally useful and not just strictly doing the bare
minimum needed to meet the CAPP requirements.
However, I think it helps in this discussion to at least keep in mind
where different requirements are coming from, since the different
expectations people have about what the audit system is supposed to do
are different enough already.
Roughly, I think there are at least the following separate goals:
- achieving basic CAPP compliance so that a product using this
implementation can be used in environments where this is formally
required.
- provide useful security event auditing during normal system operation,
similar in spirit to CAPP but differing in details, such as performance
requirements, additional flexibility needed, and maybe not insisting on
some details that CAPP specifies.
- provide information suitable for forensics in case something really
unexpected happens. Some ideas mentioned here concerned the information
available after a crash, maybe involving the exploit of a previously
unknown security flaw.
- provide a debugging tool - I hope we're mostly in agreement that this
isn't something that the audit system should be designed for, that
should be a separate tracing system that maybe shares some
infrastructure.
The point is that it's worthwhile to at least look at different
requirements, but not to get bogged down in attempts to achieve the
"perfect" system, especially if that turns out to be impossible due to
conflicting requirements. I personally think that a combination of the
first two (CAPP + real-world usefulness) is achievable but adding more
requirements runs the risk of not getting any working solution at all
anytime soon.
-Klaus
3:06 p.m.
On Tue, 2004-12-14 at 15:50, Serge E. Hallyn wrote:
Why can't you store the info in the current->audit record
until syscall
exit, and only send a message to userspace if the syscall exit says to
do so?
Another point to keep in mind is that you ultimately want to instrument
other subsystems in the same manner as the filesystem code to capture
relevant information copied by the kernel from userspace pointers (e.g.
socket addresses), and I doubt you want to keep adding all of this
object identification information into the current audit context (and
there can be mixing, e.g Unix domain socket interplay with the
filesystem, so you might need object identification information for
multiple kinds of objects on a single syscall).
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
3:23 p.m.
On Tue, Dec 14, 2004 at 04:06:08PM -0500, Stephen Smalley wrote:
On Tue, 2004-12-14 at 15:50, Serge E. Hallyn wrote:
> Why can't you store the info in the current->audit record until syscall
> exit, and only send a message to userspace if the syscall exit says to
> do so?
Another point to keep in mind is that you ultimately want to instrument
other subsystems in the same manner as the filesystem code to capture
relevant information copied by the kernel from userspace pointers (e.g.
socket addresses), and I doubt you want to keep adding all of this
object identification information into the current audit context (and
there can be mixing, e.g Unix domain socket interplay with the
filesystem, so you might need object identification information for
multiple kinds of objects on a single syscall).
I think this is the fundamental disagreement here - if you want to filter
audit records based on object identity, you need to have the object
identity information available when applying the filter rules. If you
want to do the filtering in the kernel, there isn't really any
alternative to storing this information in kernel space.
Note that I don't think that very much additional information will be
needed - the only real identity crisis identified so far (from a CAPP
perspective) have been the filesystem objects, due to the hardlink/path
issues. SYSV IPC objects each have unique identifiers available directly
in the register syscall argument with no confusion.
Socket addresses were mentioned as being useful additional information to
include in the relevant audit records and it's only available through the
userspace pointer, but I don't think anyone was proposing kernel side
filtering based on them. Keeping with the lightweight approach, I think
only the minimal amount of information should be collected that is
security relevant. I don't think the audit system is intended to be a
full-featured debugging system that can audit everything happening in a
syscall.
I think the linked-list approach mentioned may be appropriate, keeping
only the information needed for in-kernel filter decisions in directly
accessible arguments. Any other audit information could be stored in the
list and then delivered to userspace in bulk on syscall exit.
-Klaus
3:28 p.m.
* Klaus Weidner (klaus(a)atsec.com) wrote:
I think this is the fundamental disagreement here - if you want to
filter
audit records based on object identity, you need to have the object
identity information available when applying the filter rules. If you
want to do the filtering in the kernel, there isn't really any
alternative to storing this information in kernel space.
Hmm, it's been a while since I looked at CAPP audit requirements, but
doesn't it require action if log is full? E.g., possibly not allowing
request to complete?
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
3:48 p.m.
On Tue, Dec 14, 2004 at 01:28:11PM -0800, Chris Wright wrote:
* Klaus Weidner (klaus(a)atsec.com) wrote:
> I think this is the fundamental disagreement here - if you want to filter
> audit records based on object identity, you need to have the object
> identity information available when applying the filter rules. If you
> want to do the filtering in the kernel, there isn't really any
> alternative to storing this information in kernel space.
Hmm, it's been a while since I looked at CAPP audit requirements, but
doesn't it require action if log is full? E.g., possibly not allowing
request to complete?
It does, but this does not need to be instantaneous. The current plan is
that auditd notifies the kernel if it detects an "out of disk space"
condition, and this will tell the kernel that it shouldn't queue any
additional records.
When the in-kernel queue is full, any system calls that need to generate
an audit record block and wait for space to become available again. (BTW,
this may be an argument against generating audit records at arbitrary
places in the kernel, since such waiting may not be possible there.)
CAPP requires that the lossage of audit data has been minimized by the
developer and clearly documented. Losing a couple of records if the disk
is full and the system then crashes is acceptable from a CAPP point of
view.
-Klaus
4:06 p.m.
What I have currently, on disk full the auditd will notify the kernel
which sets up a falg "disk_full_flag". During audit_log_start if the
disk_full_flag is set the process will be queued in a wait queue until
auditd or auditctl reset the disk_full_flag,
I can provide more details if needed. This is the general method I am
going to use to cover this CAPP requirement.
Mounir
Mounir Bsaibes
Linux Security
Tel: (512) 838-1301
Cell: (512) 762-9957
Fax: (512) 838-8858
e-mail: bsaibes(a)us.ibm.com
Klaus Weidner <klaus(a)atsec.com>
Sent by: linux-audit-bounces(a)redhat.com
12/14/2004 03:48 PM
Please respond to
Linux Audit Discussion
To
Chris Wright <chrisw(a)osdl.org>
cc
Linux Audit Discussion <linux-audit(a)redhat.com>
Subject
Re: best way to audit in vfs
On Tue, Dec 14, 2004 at 01:28:11PM -0800, Chris Wright wrote:
* Klaus Weidner (klaus(a)atsec.com) wrote:
> I think this is the fundamental disagreement here - if you want to
filter
> audit records based on object identity, you need to have the
object
> identity information available when applying the filter rules. If you
> want to do the filtering in the kernel, there isn't really any
> alternative to storing this information in kernel space.
Hmm, it's been a while since I looked at CAPP audit requirements, but
doesn't it require action if log is full? E.g., possibly not allowing
request to complete?
It does, but this does not need to be instantaneous. The current plan is
that auditd notifies the kernel if it detects an "out of disk space"
condition, and this will tell the kernel that it shouldn't queue any
additional records.
When the in-kernel queue is full, any system calls that need to generate
an audit record block and wait for space to become available again. (BTW,
this may be an argument against generating audit records at arbitrary
places in the kernel, since such waiting may not be possible there.)
CAPP requires that the lossage of audit data has been minimized by the
developer and clearly documented. Losing a couple of records if the disk
is full and the system then crashes is acceptable from a CAPP point of
view.
-Klaus
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
10:08 a.m.
On Tue, 2004-12-14 at 17:06, Mounir Bsaibes wrote:
What I have currently, on disk full the auditd will notify the
kernel
which sets up a falg "disk_full_flag". During audit_log_start if the
disk_full_flag is set the process will be queued in a wait queue until
auditd or auditctl reset the disk_full_flag,
I can provide more details if needed. This is the general method I am
going to use to cover this CAPP requirement.
Mounir
SELinux calls the audit subsystem from hard irq (e.g.
file_send_sigiotask) and at times when kernel locks are held.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
11:48 a.m.
New subject: handling disk full
On Tue, 2004-12-14 at 17:06, Mounir Bsaibes wrote:
What I have currently, on disk full the auditd will notify the
kernel
which sets up a flag "disk_full_flag". During audit_log_start if the
disk_full_flag is set the process will be queued in a wait queue until
auditd or auditctl reset the disk_full_flag,
I can provide more details if needed. This is the general method I am
going to use to cover this CAPP requirement.
Mounir
SELinux calls the audit subsystem from hard irq (e.g.
file_send_sigiotask) and at times when kernel locks are held.
So what is a better solution, just kill the process?
I have changed the subject of this reply to make it more meaningful to
this discussion and to separate it from the audit in vfs discussion.
Mounir Bsaibes
Linux Security
Tel: (512) 838-1301
Cell: (512) 762-9957
Fax: (512) 838-8858
e-mail: bsaibes(a)us.ibm.com
Stephen Smalley <sds(a)epoch.ncsc.mil>
Sent by: linux-audit-bounces(a)redhat.com
12/15/2004 10:08 AM
Please respond to
Linux Audit Discussion
To
Linux Audit Discussion <linux-audit(a)redhat.com>
cc
Subject
Re: best way to audit in vfs
On Tue, 2004-12-14 at 17:06, Mounir Bsaibes wrote:
What I have currently, on disk full the auditd will notify the
kernel
which sets up a falg "disk_full_flag". During audit_log_start if the
disk_full_flag is set the process will be queued in a wait queue until
auditd or auditctl reset the disk_full_flag,
I can provide more details if needed. This is the general method I am
going to use to cover this CAPP requirement.
Mounir
SELinux calls the audit subsystem from hard irq (e.g.
file_send_sigiotask) and at times when kernel locks are held.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
11:53 a.m.
New subject: handling disk full
On Wed, 2004-12-15 at 12:48, Mounir Bsaibes wrote:
So what is a better solution, just kill the process?
I have changed the subject of this reply to make it more meaningful to
this discussion and to separate it from the audit in vfs discussion.
There may not be any local process associated with the event, e.g.
SELinux can generate audit data during processing of received packets.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
12:01 p.m.
New subject: handling disk full
Keep in mind that the CAPP audit requirements are fairly independent from
the SELinux uses of the audit subsystem.
CAPP requires that specific actions don't complete if they can't be
audited, and those events will in general occur from a syscall context
where a sleep should not be a problem.
The events generated by SELinux are not required by CAPP, and it's not a
problem for CAPP compliance if those messages get discarded if there is
no room for them and the kernel can't sleep.
Things get more complicated if you're looking at an LSPP system with
SELinux being responsible for audit events related to labels which aren't
optional.
-Klaus
On Wed, Dec 15, 2004 at 11:48:25AM -0600, Mounir Bsaibes wrote:
On Tue, 2004-12-14 at 17:06, Mounir Bsaibes wrote:
> What I have currently, on disk full the auditd will notify the kernel
> which sets up a flag "disk_full_flag". During audit_log_start if the
> disk_full_flag is set the process will be queued in a wait queue until
> auditd or auditctl reset the disk_full_flag,
> I can provide more details if needed. This is the general method I am
> going to use to cover this CAPP requirement.
> Mounir
SELinux calls the audit subsystem from hard irq (e.g.
file_send_sigiotask) and at times when kernel locks are held.
So what is a better solution, just kill the process?
I have changed the subject of this reply to make it more meaningful to
this discussion and to separate it from the audit in vfs discussion.
Mounir Bsaibes
Linux Security
Tel: (512) 838-1301
Cell: (512) 762-9957
Fax: (512) 838-8858
e-mail: bsaibes(a)us.ibm.com
Stephen Smalley <sds(a)epoch.ncsc.mil>
Sent by: linux-audit-bounces(a)redhat.com
12/15/2004 10:08 AM
Please respond to
Linux Audit Discussion
To
Linux Audit Discussion <linux-audit(a)redhat.com>
cc
Subject
Re: best way to audit in vfs
On Tue, 2004-12-14 at 17:06, Mounir Bsaibes wrote:
> What I have currently, on disk full the auditd will notify the kernel
> which sets up a falg "disk_full_flag". During audit_log_start if the
> disk_full_flag is set the process will be queued in a wait queue until
> auditd or auditctl reset the disk_full_flag,
> I can provide more details if needed. This is the general method I am
> going to use to cover this CAPP requirement.
> Mounir
SELinux calls the audit subsystem from hard irq (e.g.
file_send_sigiotask) and at times when kernel locks are held.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
12:09 p.m.
New subject: handling disk full
On Wed, 2004-12-15 at 13:01, Klaus Weidner wrote:
Keep in mind that the CAPP audit requirements are fairly independent
from
the SELinux uses of the audit subsystem.
CAPP requires that specific actions don't complete if they can't be
audited, and those events will in general occur from a syscall context
where a sleep should not be a problem.
1) What does "can't be audited" mean - that we couldn't send the audit
record to userspace or that it couldn't reach the disk?
2) Even from process context, you'd have to make sure that the caller is
never holding a lock when it calls audit_log*.
The events generated by SELinux are not required by CAPP, and
it's not a
problem for CAPP compliance if those messages get discarded if there is
no room for them and the kernel can't sleep.
Possibly, but audit_log* can't automatically detect whether it is safe
to sleep. Caller will have to provide that information via a flag or
alternate interface.
In any event, use of sigsuspend seems questionable.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
12:40 p.m.
New subject: handling disk full
We are talking about 2 different things: 1) handling disk full 2)
suspending the process whenever there are no kernel resources.
1) For handling disk full I am doing the following:
Whenever the disk full (or log reached its limit) is detected the auditd
sends an AUDIT_SUSPEND message to the kernel. On receipt of this message
the kernel will set a flag "disk_full_flag". If this disk_full_flag is
set audit_log_start will call audit_suspend to queue the process in a wait
queue. Whenever the disk_full_flag is reset all the processes in the wait
queue will be rescheduled.
2) For suspending the process whenever there are no kernel resources:
I was thinking of using sigsuspend whenever audit_log_lost is called
depending on the "failure flag". The failure flag currently can be set
,only, to: do nothing, print a message or panic. I was thinking to add a
fourth option to this flag to suspend the processes.
sigsuspend puts the process in the TASK_INTERRUPTIBLE state, the process
will only wake up when a nonignored, nonblocked signal is sent to it. From
the dicussion so far this may not be a good way to go about solving this
requirement, specially if the process is holding locks or whatever. I need
to either add to this solution or come up with a different one.
Mounir Bsaibes
Linux Security
Tel: (512) 838-1301
Cell: (512) 762-9957
Fax: (512) 838-8858
e-mail: bsaibes(a)us.ibm.com
Stephen Smalley <sds(a)epoch.ncsc.mil>
Sent by: linux-audit-bounces(a)redhat.com
12/15/2004 12:09 PM
Please respond to
Linux Audit Discussion
To
Linux Audit Discussion <linux-audit(a)redhat.com>
cc
Subject
Re: handling disk full
On Wed, 2004-12-15 at 13:01, Klaus Weidner wrote:
Keep in mind that the CAPP audit requirements are fairly independent
from
the SELinux uses of the audit subsystem.
CAPP requires that specific actions don't complete if they can't be
audited, and those events will in general occur from a syscall context
where a sleep should not be a problem.
1) What does "can't be audited" mean - that we couldn't send the audit
record to userspace or that it couldn't reach the disk?
2) Even from process context, you'd have to make sure that the caller is
never holding a lock when it calls audit_log*.
The events generated by SELinux are not required by CAPP, and
it's not a
problem for CAPP compliance if those messages get discarded if there is
no room for them and the kernel can't sleep.
Possibly, but audit_log* can't automatically detect whether it is safe
to sleep. Caller will have to provide that information via a flag or
alternate interface.
In any event, use of sigsuspend seems questionable.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
12:53 p.m.
New subject: handling disk full
* Mounir Bsaibes (bsaibes(a)us.ibm.com) wrote:
We are talking about 2 different things: 1) handling disk full 2)
suspending the process whenever there are no kernel resources.
1) For handling disk full I am doing the following:
Whenever the disk full (or log reached its limit) is detected the auditd
sends an AUDIT_SUSPEND message to the kernel. On receipt of this message
the kernel will set a flag "disk_full_flag". If this disk_full_flag is
set audit_log_start will call audit_suspend to queue the process in a wait
queue. Whenever the disk_full_flag is reset all the processes in the wait
queue will be rescheduled.
Look at audit_log_start callers. They include avc_perm, which can happen
in interrupt context. Notice audit_log_start() is already coded to be
called from nearly any context, it uses _irq versions of spinlock and
does GFP_ATOMIC allocations.
2) For suspending the process whenever there are no kernel
resources:
I was thinking of using sigsuspend whenever audit_log_lost is called
depending on the "failure flag". The failure flag currently can be set
,only, to: do nothing, print a message or panic. I was thinking to add a
fourth option to this flag to suspend the processes.
sigsuspend puts the process in the TASK_INTERRUPTIBLE state, the process
will only wake up when a nonignored, nonblocked signal is sent to it. From
the dicussion so far this may not be a good way to go about solving this
requirement, specially if the process is holding locks or whatever. I need
to either add to this solution or come up with a different one.
The best you could do is wait until syscall exit and queue up processes
then. The action will have taken place, but the caller wouldn't get
scheduled until it's awoken by audit system. (This doesn't help for the
case of creating something that another process could then use, as it
will exist, and the other process's access to object may not be an
auditable event).
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
2:33 p.m.
New subject: handling disk full
On Wed, Dec 15, 2004 at 10:53:33AM -0800, Chris Wright wrote:
The best you could do is wait until syscall exit and queue up
processes
then. The action will have taken place, but the caller wouldn't get
scheduled until it's awoken by audit system. (This doesn't help for the
case of creating something that another process could then use, as it
will exist, and the other process's access to object may not be an
auditable event).
That won't do, the CAPP requirement is specifically that the action is
prevented. The approach you describe could be abused to do arbitrarily
many audit-required events by forking separate processes for them if you
don't care about them getting stuck afterwards.
-Klaus
4:04 p.m.
New subject: handling disk full
* Klaus Weidner (klaus(a)atsec.com) wrote:
On Wed, Dec 15, 2004 at 10:53:33AM -0800, Chris Wright wrote:
> The best you could do is wait until syscall exit and queue up processes
> then. The action will have taken place, but the caller wouldn't get
> scheduled until it's awoken by audit system. (This doesn't help for the
> case of creating something that another process could then use, as it
> will exist, and the other process's access to object may not be an
> auditable event).
That won't do, the CAPP requirement is specifically that the action is
prevented. The approach you describe could be abused to do arbitrarily
many audit-required events by forking separate processes for them if you
don't care about them getting stuck afterwards.
Your alternative is to create a blocking version and then make sure
it's not called with locks held. Or create some reservation scheme on
syscall entry, which could be tough with multiple auditable events in
one syscall.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
3:42 p.m.
New subject: handling disk full
On Wed, 2004-12-15 at 13:40, Mounir Bsaibes wrote:
We are talking about 2 different things: 1) handling disk full 2)
suspending the process whenever there are no kernel resources.
1) For handling disk full I am doing the following:
Whenever the disk full (or log reached its limit) is detected the
auditd sends an AUDIT_SUSPEND message to the kernel. On receipt of
this message the kernel will set a flag "disk_full_flag". If this
disk_full_flag is set audit_log_start will call audit_suspend to
queue the process in a wait queue. Whenever the disk_full_flag is
reset all the processes in the wait queue will be rescheduled.
2) For suspending the process whenever there are no kernel resources:
I was thinking of using sigsuspend whenever audit_log_lost is called
depending on the "failure flag". The failure flag currently can be set
,only, to: do nothing, print a message or panic. I was thinking to
add a fourth option to this flag to suspend the processes.
sigsuspend puts the process in the TASK_INTERRUPTIBLE state, the
process will only wake up when a nonignored, nonblocked signal is sent
to it. From the dicussion so far this may not be a good way to go
about solving this requirement, specially if the process is holding
locks or whatever. I need to either add to this solution or come up
with a different one.
I'm not entirely clear on the distinction above (i.e. why you don't just
handle both situations in the same manner). But in any event, the
processing you describe can only safely be done from either:
a) audit_syscall_exit, or
b) some new audit_log* functions that are explicitly identified as
potentially blocking.
You can't change the existing audit_log* functions or core helper
functions used by them to suddenly start blocking (or you at least have
to allow a flag to preserve the current non-blocking behavior), because
current users of the audit system rely on the ability to call audit_log*
from any context. This is similar to printk, which also strives to be
useable from any context.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
1:16 p.m.
New subject: handling disk full
On Wed, Dec 15, 2004 at 01:09:01PM -0500, Stephen Smalley wrote:
On Wed, 2004-12-15 at 13:01, Klaus Weidner wrote:
> Keep in mind that the CAPP audit requirements are fairly independent from
> the SELinux uses of the audit subsystem.
>
> CAPP requires that specific actions don't complete if they can't be
> audited, and those events will in general occur from a syscall context
> where a sleep should not be a problem.
1) What does "can't be audited" mean - that we couldn't send the audit
record to userspace or that it couldn't reach the disk?
The more abstract requirement is that the implementation minimizes the
potential loss of audit records in a way that makes the maximum lossage
predictable, and ideally configurable based on admin preferences for a
reliability/performance tradeoff.
In this context, it would mean that the kernel knows that it won't be
able to send the record to userspace, for example because the queue is
full. auditd should let the kernel know in some way when it's out of
disk space to stop further events from being queued.
Quoting from CAPP (also LSPP, its requirements here are identical):
5.1.7 Guarantees of Audit Data Availability (FAU_STG.1)
5.1.7.1 The TSF shall protect the stored audit records from
unauthorized deletion. FAU_STG.1.1
5.1.7.2 The TSF shall be able to prevent modifications to the
audit records. FAU_STG.1.2
Application Note: On many systems, in order to reduce the
performance impact of audit generation, audit records will be
temporarily buffered in memory before they are written to
disk. In these cases, it is likely that some of these records
will be lost if the operation of the TOE is interrupted by
hardware or power failures. The developer needs to document
what the likely loss will be and show that it has been
Rationale: This component supports the O.AUDITING objective by
protecting the audit trail from tampering, via deletion or
modification of records in it. Further it ensures that it is
as complete as possible.
5.1.9 Prevention of Audit Data Loss (FAU_STG.4)
5.1.9.1 The TSF shall be able to prevent auditable events, except
those taken by the authorized administrator, and [assignment:
other actions to be taken in case of audit storage failure] if
the audit trail is full. FAU_STG.4.1 / NOTE 5
Application Note: The selection of "preventing" auditable
actions if audit storage is exhausted is minimal
functionality; providing a range of configurable choices
(e.g., ignoring auditable actions and/or changing to a
degraded mode) is allowable, as long as "preventing" is one of
the choices. If configurable, then FMT_MOF.1 should be
incorporated into the ST.
Rationale: This component supports the O.AUDITING and O.MANAGE
objectives by providing the audit trail is complete with
respect to non-administrative users while providing
administrators with the ability to recover from the situation.
2) Even from process context, you'd have to make sure that the
caller is
never holding a lock when it calls audit_log*.
That's a potential advantage of generating audit events in the syscall
path.
> The events generated by SELinux are not required by CAPP, and
it's not a
> problem for CAPP compliance if those messages get discarded if there is
> no room for them and the kernel can't sleep.
Possibly, but audit_log* can't automatically detect whether it is safe
to sleep. Caller will have to provide that information via a flag or
alternate interface.
Yes, and it's not pretty...
In any event, use of sigsuspend seems questionable.
I think it needs to be an in-kernel sleep, since a sigsuspend could be
undone by a sigresume from a different process.
-Klaus
4:41 p.m.
On Tue, 2004-12-14 at 13:28 -0800, Chris Wright wrote:
Hmm, it's been a while since I looked at CAPP audit requirements,
but
doesn't it require action if log is full? E.g., possibly not allowing
request to complete?
Still in there I think - has been since C2. Never turned on in ANY
agency I've ever been to though, so I don't recommend stressing too much
over the implementation. ;)
L.
--
Leigh Purdie, Director - InterSect Alliance Pty Ltd
http://www.intersectalliance.com/
3:29 p.m.
On Tue, 2004-12-14 at 16:23, Klaus Weidner wrote:
I think this is the fundamental disagreement here - if you want to
filter
audit records based on object identity, you need to have the object
identity information available when applying the filter rules. If you
want to do the filtering in the kernel, there isn't really any
alternative to storing this information in kernel space.
If you can determine within the hook function itself whether or not you
need to emit an audit record, then it can make that determination (based
on object identity, current process information, particular hook, etc)
in isolation, and you don't need to save any state temporarily. You can
just immediately have the hook function emit an audit record with the
information available to it, and that automatically enables generation
of an audit record upon syscall exit that includes the syscall number,
return code, args, pathname info, etc. That is what SELinux does today.
I think the linked-list approach mentioned may be appropriate,
keeping
only the information needed for in-kernel filter decisions in directly
accessible arguments. Any other audit information could be stored in the
list and then delivered to userspace in bulk on syscall exit.
While that is possible (and necessary if you truly need complex audit
policies based on more than what one hook can decide), it does mean that
you don't get any audit notification until operation completion (and
possibly none at all in the event of a crash), which might be
undesirable if the auditable object was detected very early in
processing the operation (or if the operation itself produced the crash
_after_ an audit determination could have already been made).
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
4:07 p.m.
On Tue, Dec 14, 2004 at 04:29:52PM -0500, Stephen Smalley wrote:
> I think the linked-list approach mentioned may be appropriate,
keeping
> only the information needed for in-kernel filter decisions in directly
> accessible arguments. Any other audit information could be stored in the
> list and then delivered to userspace in bulk on syscall exit.
While that is possible (and necessary if you truly need complex audit
policies based on more than what one hook can decide),
As Tim mentioned in another branch of this thread, only coarse
prefiltering for performance needs to be in the kernel, more complex
decisions can be done in userspace if needed. CAPP only requires that
filters can be set by user identity, which is trivial.
it does mean that you don't get any audit notification until
operation
completion (and possibly none at all in the event of a crash), which
might be undesirable if the auditable object was detected very early in
processing the operation (or if the operation itself produced the crash
_after_ an audit determination could have already been made).
Note that this kind of crash robustness goes far beyond what CAPP (and
LSPP) require, and would depend on synchronous message passing to auditd,
with the kernel waiting until auditd has synced the message to disk
before proceeding with the next step in syscall execution. I think that's
a different type of audit than the security audit records that the
current design was supposed to provide.
-Klaus
4:39 p.m.
On Tue, 2004-12-14 at 16:06 -0500, Stephen Smalley wrote:
Another point to keep in mind is that you ultimately want to
instrument
other subsystems in the same manner as the filesystem code to capture
relevant information copied by the kernel from userspace pointers (e.g.
socket addresses), and I doubt you want to keep adding all of this
object identification information into the current audit context (and
there can be mixing, e.g Unix domain socket interplay with the
filesystem, so you might need object identification information for
multiple kinds of objects on a single syscall).
Just as an addendum to Stephen's comments:
There are generally few items-of-interest to a system auditor associated
with a system call.
For most system calls, the auditor wants to know: Who, when, what, and
success.
* The 'who' breaks down to EUID/EGID (and sometimes RUID/RGID).
* The 'when' is a local timestamp down to seconds (milliseconds are only
important if the audit subsystem can potentially report events out of
'sequence'.
* The 'what' is system call dependent, but is usually one or two key
items.
- For execve, the binary (with path), and arguments.
- For file opens, the filename, and open flags (generally, broken down
to either 'read' or 'write').
- For renames, the source and destination paths.
- For 'accepts', the source IP and the destination port.
- For 'connects', the destination IP and the destination port.
* The 'success' is whether the system call failed or succeeded.
I guess what I'm saying, is that you shouldn't need to go overboard,
trying to store every single attribute of a particular system call -
there are only a few that are going to be of interest to an auditor at
the end of the day.
Additional details are great for debugging... but leave that to strace
to cover. :)
Leigh.
--
Leigh Purdie, Director - InterSect Alliance Pty Ltd
http://www.intersectalliance.com/
2:30 p.m.
* Timothy R. Chavez (chavezt(a)gmail.com) wrote:
I've been kind of thinking about this. Presumably, we want to
audit
both failed and successful attempts in whatever vfs function we happen
to be in. For instance, if we fall out of vfs_mkdir because
may_create returned an error, we'd like to receive an audit message
that said something like, "filename=myfile syscall= mkdir()
error=<errno>.....", but, would I want to do this by hooking each
conditional statement? Is there a better approach? The only other
one I can think of would be to have one exit point in the functions
and audit right before we exit...
You already get syscall entry/exit with audit. So all you need is the
intermediate step.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
7311
days inactive
7312
days old
linux-audit@lists.linux-audit.osci.io
55 comments
7 participants
participants (7)
-
Chris Wright -
Klaus Weidner -
Leigh Purdie -
Mounir Bsaibes -
Serge E. Hallyn -
Stephen Smalley -
Timothy R. Chavez