user message limits
by LC Bruzenak
I know I can go look at the code, however I figured I'd ask here first
about the limits on the user message in both audit_log_user_message and
ausearch.
With audit_log_user_message the maximum length allowed appears to be
around MAX_AUDIT_MESSAGE_LENGTH-100. I think it may depend on the
executable name length (and other stuff auto-pushed into the string)
which is why I say "around".
Even when I get a successful return value (from audit_log_user_message),
I don't get my string back out in "ausearch" unless it is WAY smaller -
~1K or less I think.
Any ideas/thoughts?
This is the latest (1.7.11-2) audit package.
Thx,
LCB.
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
11 years, 3 months
AUDIT_SIGNAL_INFO
by Matthew Booth
Under what circumstances will the RHEL 4 kernel generate a message of
type AUDIT_SIGNAL_INFO? My understanding is that it should be sent when
a process sends a signal to the audit daemon, however I have not
observed that. Any ideas?
Thanks,
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat, Global Professional Services
M: +44 (0)7977 267231
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
12 years, 6 months
Near Term Audit Road Map
by Steve Grubb
Hi,
With the proposals sent to the list, I wanted to talk about how this might
play out code-wise. With regard to the current code base, I am working on a
1.8 release. This would represent finishing the remote logging app and
nothing more. The 1.8 series would become just an update series just like the
1.0.x series did.
In parallel with finishing remote logging, I would release a 2.0 version.
Patches applied to 1.8 would also be applied to 2.0. A 2.1 release would
signify the completion of remote logging that branch. I would recommend this
branch for all distributions pulling new code in.
The 2.0 branch will also have a couple more changes. I want to split up the
audit source code a little bit. I want to drop the system-config-audit code
and let it become standalone package updated and distributed separately.
I also want to drop all audispd-plugins in the 2.0 branch and have them
released separately. They cause unnecessary build dependencies for the audit
package.
During the work for a 2.2 release, I would also like to pull the audispd
program inside auditd. In the past, I tried to keep auditd lean and single
purpose, but with adding remote logging and kerberos support, we already have
something that is hard to analyze. So, to improve performance and decrease
system load, the audit daemon will also do event dispatching.
Would this proposal impact anyone in a Bad Way?
Thanks,
-Steve
12 years, 6 months
Re: PATCH [1/1]: audit: acquire creds selectively to reduce atomic op overhead
by Tony Jones
On Wed, Apr 27, 2011 at 03:12:23PM +0200, Jiri Kosina wrote:
> I don't see the patch in linux-next as of today. As it has been acked by
> subsystem maintainer, I have picked it up into my tree ("retransmission
> mode").
>
> If anyone has any objections, please let me know. Thanks.
I spoke to Eric about this 10 days ago and he was going to create an audit
tree for the next window.
Tony
13 years, 8 months
audit-2.1.1 released
by Steve Grubb
Hi,
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
soon. The ChangeLog is:
- When ausearch is interpretting, output "as is" if no = is found
- Correct socket setup in remote logging
- Adjusted a couple default settings for remote logging and init script
- Audispd was not marking restarted plugins as active
- Audisp-remote should keep a capability if local_port < 1024
- When audispd restarts plugin, send event in its preferred format
- In audisp-remote, make all I/O asynchronous
- In audisp-remote, add sigusr1 handler to dump internal state
- Fix autrace to use correct syscalls on s390 and s390x systems
- Add shutdown syscall to remote logging teardowns
- Correct autrace rule for 32 bits systems
The main focus of this release is making the remote logging more robust. We found and
fixed several problems related to all aspects of remote logging. Audispd was not
marking restarted plugins as active and even when it did that, it sent the plugin data
in the non-string format the first time which generally results in missed events. There
was a problem where we dropped all privs in the remote plugin, but if the port was
privileged, reconnecting on a broken connection would fail. A sigusr1 handler was
added so that you can make the remote logging plugin dump some info about its internal
state for troubleshooting.
Aside from that, there was a little work on autrace to correct i386/686 and s390's so
that it works as intended.
Please let me know if you run across any problems with this release.
-Steve
13 years, 8 months
Auditing failures for files in protected directories - Lockheed Martin Proprietary/Export Controlled Information
by Call, Tom H
Lockheed Martin Proprietary/Export Controlled Information
Proprietary information owned by Lockheed Martin, such as business, financial or technical information, that requires protection from unauthorized disclosure, and is subject to US or foreign export control laws or regulations.
.
.
.
Message Start:
-----------------------
Steve,
Hi, we have what I think is a new but undesirable result trying to audit access failures on files in a NISPOM audit configuration.
We are not seeing audit events for the access failures if the file has a parent directory in the path that blocks access.
Example:
Directory Permission
/var 755
/var/test 755
/var/test/bin 700
/var/test/bin/file 740
If an unprivileged user attempts to change /var/test/bin/file there is no audit event recorded, either for the file or the parent directory /var/test/bin.
Our theory is that the failure to open the /var/test/bin directory causes the audit path to be broken, or something to the like, please excuse my terminology faux pas.
This is happening on the following configuration:
- Kernel - 2.6.18-238.5.1.el5
- Auditd - 1.7.18-2.el5
We have tried the following auditd rules (among others), no change in result:
- -w /var/test/bin/file -p rwxa
- -a exit,always -S open -F path=/var/test/bin/file -F success=0
- -a exit,always -S open -R dir=/var/test/ -F success=0
And, this is something New, we have been using watches to audit this file for years with previous kernel and auditd versions, such as:
- Kernel - 2.6.9-100.ELsmp
- Auditd - 1.0.16-4.el4_8.1
On this system we get audit events for access failures using a simple file watch.
Are we missing something obvious?
Thanks! For any help,
Tom Call, LMCO
13 years, 8 months
Ausearch message types
by Steve M. Zak
Hi,
Where can I find a definition list for the ausearch message types? I didn't find anything on google or in the man page.
Steve Grubb referenced -m RESP_ACC_LOCK (account lockout) and -m USER_AUTH (user authentication)
I'd like to know what the other ones can do.
Thanks!
____________________________________________
Steve M. Zak,
--
This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com
13 years, 8 months
Bad bug in remote logging
by Steve Grubb
Hello,
There was a bug reported to day that I think merits an email and/or discussion.
https://bugzilla.redhat.com/show_bug.cgi?id=695419
=================================
audisp-remote does
> memset (&address, 0, sizeof(address));
> address.sin_family = htons(AF_INET);
> address.sin_port = htons(config.local_port);
> address.sin_addr.s_addr = htonl(INADDR_ANY);
which shows in strace as
> bind(3, {sa_family=0x200 /* AF_??? */, sa_data="\0<\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) =
0
For some reason the call still succeeds, but a correct invocation would not
call htons on AF_INET.
================================
The reason it succeeds is because there is a matching mistake in auditd. So, what this
means is that remote logging is not using IPv4, but something else. I committed a
patch to fix this in trunk:
https://fedorahosted.org/audit/changeset/505
This would cause new systems and old systems to not be able to talk to one another.
Regarding RHEL, remote logging has been tech preview, meaning that its alpha code and
likely buggy but available so you can see where this is heading. So, I think we can
just change it to be correct. For Fedora, there is no tech preview and everything is
supported...but it has a short life. However, what the code was doing is clearly
wrong. So, I am thinking to fix this all the way back to F-13 if I can. Regarding other
distributions...not sure what the support status is or how they would like to choose
to solve this. Anyone have any thoughts on this?
-Steve
13 years, 8 months
