audit 1.1.1 released
by Steve Grubb
Hello,
I've just released a new version of the audit daemon. It can be downloaded
from http://people.redhat.com/sgrubb/audit It will also be in rawhide
tomorrow. The Changelog is:
- Add support for alpha processors
- Update the audisp code
- Add locale code in ausearch and aureport
- Add new rule operator patch
- Add exclude filter patch
- Cleanup make files
- Add python bindings
In this release, audisp is still just a placeholder. The other features are
self explanatory.
Please let me know if there are any problems.
-Steve
19 years
[PATCH] cleanup audit name handling
by Amy Griffis
Cleanup handling of name field: "(null)" is a legit filename, so don't
use it for a placeholder.
Signed-off-by: Amy Griffis <amy.griffis(a)hp.com>
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -751,7 +751,7 @@ static inline void audit_free_names(stru
for (i = 0; i < context->name_count; i++) {
printk(KERN_ERR "names[%d] = %p = %s\n", i,
context->names[i].name,
- context->names[i].name ?: "(null)");
+ context->names[i].name ?: "");
kfree(context->names[i].ctx);
}
dump_stack();
@@ -1025,11 +1025,10 @@ static void audit_log_exit(struct audit_
audit_log_format(ab, "item=%d", i);
- audit_log_format(ab, " name=");
- if (context->names[i].name)
+ if (context->names[i].name) {
+ audit_log_format(ab, " name=");
audit_log_untrustedstring(ab, context->names[i].name);
- else
- audit_log_format(ab, "(null)");
+ }
if (pino != (unsigned long)-1)
audit_log_format(ab, " parent=%lu", pino);
@@ -1275,7 +1274,7 @@ void audit_putname(const char *name)
for (i = 0; i < context->name_count; i++)
printk(KERN_ERR "name[%d] = %p = %s\n", i,
context->names[i].name,
- context->names[i].name ?: "(null)");
+ context->names[i].name ?: "");
}
#endif
__putname(name);
19 years
Keeping log files
by Mont Rothstein
We want to keep all log files. This presents two problems, space and
rotation time.
To address space I want to compress the log files (bzip2).
To address rotation time all I can think to do is not rotate and instead use
cron to periodically rename (with the date), and compress the log file.
My concern is how to safely get the existing logs and start from scratch
without potentially loosing log entries. If I copy the log file and then use
/dev/null to clear the existing file, then there is a window between the cp
and the /dev/null. If I move the file will a HUP sent to auditd break the
connection to the old logfile and start a new one?
Has anyone else done this? Is there a better option than the ones I've
listed here?
Thanks,
-Mont
19 years, 1 month
Directory structure auditing - a case
by Mont Rothstein
It was suggested to me that readers of this list might be interested in
hearing our use case for directory structure auditing (auditing all of the
files below a directory). So here it is.
We write digital asset management (management of photos, sound files, video
files, etc.) software for law enforcement agencies.
These agencies are not only interested in whether a digital asset is
untouched (for which we assign a hash), but also in who has had access to
any given file and what they did with it (read, write, ???.).
The number of files could be in the millions, far too many to add a rule for
each file.
Building a rule for each user is not only operationally undesirable it would
also mean that if those users actually logged into the server every file
they accessed would be logged, not just the files we care about.
We want/need to catch all access to the files in our directory structure
including any management/administrative access, therefore we would like
*all* users access to these files logged, not just a subset of common
(non-admin) users.
That is it. Not terribly complex.
If anyone has any questions I will do my best to answer them.
-Mont
19 years, 1 month
Re: Another error message in current test kernel
by Randy Zagar
On Thu, 2005-11-17 at 09:03:58 -0500 sds(a)tycho.nsa.gov wrote:
> Message: 5
> Date: Thu, 17 Nov 2005 09:03:58 -0500
> From: Stephen Smalley <sds(a)tycho.nsa.gov>
> Subject: Re: Another error message in current test kernel
> To: Steve Grubb <sgrubb(a)redhat.com>
> Cc: Linux Audit Discussion <linux-audit(a)redhat.com>
> Message-ID: <1132236238.17726.20.camel(a)moss-spartans.epoch.ncsc.mil>
> Content-Type: text/plain
>
> On Wed, 2005-11-16 at 17:12 -0500, Steve Grubb wrote:
> > On Wednesday 16 November 2005 15:04, Stephen Smalley wrote:
> > > > Nov 16 09:21:00 localhost kernel: inode_doinit_with_dentry:
> > > > context_to_sid(root:object_r:fileop_exec_t:s0) returned 22 for dev=sda7
> > > > ino=3761512
> > >
> > > That just means that you previously had the selinux testsuite policy
> > > loaded, and then later removed it, thereby invalidating that type (and
> > > thus any incore inode labels that contained it).
> >
> > Correct...how would a normal user know that? Is this an error, warning, or
> > info? Does this message need to be worded more ominously? What is the fix for
> > this?
>
> The message could be clearer, particularly for the common case (e.g.
> SELinux: inode %ld on dev %s has invalid security context %s, treating
> as unlabeled.) It is presently a printk in
> hooks.c:inode_doinit_with_dentry; could be converted to using audit_log.
> There are a number of printks performed by hooks.c that are potentially
> candidates for using the audit system instead.
>
> The fix for the reported error is to relabel the inode to a valid
> security context. Until that happens, SELinux treats it as having the
> unlabeled context and thus makes it inaccessible to unprivileged
> confined processes.
As one of those pesky end-users who's spent the past 20 years reading
syslog entries, I have to agree with Steve that the above entry not only
fails to inspire me to take action, it fails to give me any indication
of what to do.
As it stands now, only the SELinux developers and people who are expert
at crafting SELinux policy rules will understand this log entry.
Specifically,
What is error 22?
Am I expected to read selinux.h to find out what that error code
means? What if I didn't install kernel development tools? Can
you depend on that file actually being present on the system?
No, you can't.
There is a nice little function called perror() defined in the
standard C library that translates error codes into human. You
might actually consider implementing something similar, and then
use it.
And
Which file is inode 3761512?
Even if I understand the error message and know I have to
"relabel the inode to a valid security context", how will I
determine what security context SHOULD be applied without
knowing the filename?
For instance, one of the things my systems have to do is
generate an audit record for "unsuccessful attempts to access
security-relevant objects" (NISPOM Chapter 8).
Typically, this means catching people trying to read /etc/shadow
or /var/log/secure. But I also have to audit accesses to our
antivirus software and our auditing software.
I don't define security-relevant objects in terms of inodes, so
error messages that report security policy problems in terms of
inodes will have no meaning to me.
-RZ
--
Randy Zagar Sr. Unix Systems Administrator
E-mail: zagar(a)arlut.utexas.edu Applied Research Laboratories
Phone: 512 835-3131 Univ. of Texas at Austin
19 years, 1 month
Another error message in current test kernel
by Steve Grubb
Hi,
This was in syslog:
Nov 16 09:21:00 localhost kernel: inode_doinit_with_dentry:
context_to_sid(root:object_r:fileop_exec_t:s0) returned 22 for dev=sda7
ino=3761512
Ring any bells?
-Steve
19 years, 1 month
Re: Auditing file access below a directory
by Matt Anderson
Mont Rothstein wrote:
> I am trying to determine if it is possible to audit all file access under a
> directory for all users.
>
> I've been looking at auditd/auditctl and it seems like only individual files
> or directories can be watched, but not directory trees.
>
> My current work around is to audit the gid of the default group for all of
> the users I care about (accessing the server as a file server via samba).
>
> This is obviously not ideal.
>
> Does anyone know if there is a way to do this?
>
> Thanks,
> -Mont
>
> P.S. This seemed to be the appropriate list for this. If it isn't I
> apologize.
This is perhaps a better list for your question.
19 years, 1 month
Freeing multiple contexts message
by Steve Grubb
Hi,
I think we need to change the message in audit_free_context(). It currently
says:
"audit(:%d): major=%d name_count=%d: freeing multiple contexts (%d)\n"
This does not really indicate to the casual user that they've encountered a
bug that needs to be reported. Is there a common method to flag kernel bugs
that gets a user's attention? BUG_ON? WARN_ON?
Also, does this message contain enough information for troubleshooting if
someone reports it? Should it contain the syscall number, task name, or is
anything else needed?
-Steve
19 years, 1 month
