[PATCH] fix generic user message
by Steve Grubb
Hello,
If you do:
auditctl -m "New Message"
it fails since the original user message wasn't consolidated in the case
statement range. The attached patch fixes the kernel so the old messages work
again.
Signed-off-by: Steve Grubb<sgrubb(a)redhat.com>
21 years
Fw: User message text reduction
by Kris Wilson
David Woodhouse:
>OK, then I can reject the patch. However, it would be unfortunate to
>release RHEL4 U2 with this kind of inconsistency -- would I be right to
>believe that it's OK to change it between the 'U1+audit' which is being
>tested and the final U2 product?
OK, after getting some sleep and thinking it over, it would be better
for us to take the hit now and not later when the tests are in LTP. so
fire away on this one, but please keep test impact in mind as new ideas
arise. Thanks.
21 years
audit 0.8.2 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:
- Update documentation
- Handle user space audit events in more uniform way
- Update all parsers for more robustness with new kernel changes
- Create quiet mode for error messages
- Make rotated logs readonly
This is mostly a bug fix release. It also has parsing updates for ausearch to
match the loginuid -> auid change.
-Steve
21 years
audit.44 kernel
by David Woodhouse
I seem to be building them faster than I can announce them.
When testing socketcall code I observed that auditd was logging its own
actions, which soon descended into insanity as it generated two more log
entries for every one that it read from the socket. I have added code to
auditsc.c to exempt the audit_pid from being audited -- see attached
patch. The rest of it is just getting the skb queueing via kernel dæmon
working properly...
* Thu May 19 2005 David Woodhouse <dwmw2(a)redhat.com> audit.44
- Honour audit_backlog_limit again
- Reorder patches to reflect upstream status
* Thu May 19 2005 David Woodhouse <dwmw2(a)redhat.com> audit.43
- printk in audit_log_end() when no auditd
- Don't audit auditd itself
* Wed May 18 2005 David Woodhouse <dwmw2(a)redhat.com> audit.42
- Restore Chris' third audit-to-skb patch
--
dwmw2
21 years
User message text reduction
by Steve Grubb
Hello,
I was repatching the trusted apps and got to looking at the resulting
messages. The attached patch: removes uid - not needed since its always 0,
removes length - who cares, and changes loginuid to auid for consistency.
-Steve
21 years
audit capability checks not audited
by Stephen Smalley
Hi,
We're starting to see bug reports of SELinux denials with no audit
messages in FC4/devel due to the fact that the audit capabilities are
checked on the receive side via a direct cap_raised() test on the
effective capability set saved earlier by the netlink_send hook. This
manifests as programs failing in enforcing mode and working in
permissive mode, but no audit messages being generated. I know there
was an earlier rfc/patch by Chris to allow moving the netlink message
checking to the send side via a new callback, which would allow us to
perform a traditional capable() call rather than a direct cap_raised()
test and thus have the usual auditing behavior for SELinux there. Is
that stalled?
--
Stephen Smalley
National Security Agency
21 years
Rotation of audit logs
by Kris Wilson
I just reran the stress test using audit 8-1 and the .40 kernel, and I have
a question
about the continuation of records from one log file to another.
End of audit.log.1:
type=PATH msg=audit(1116457159.607:12637620): item=0 name="stress2_dir"
type=SYSCALL msg=audit(1116457159.607:12637620): syscall=90 arch=c000003e success=no exit=-2 a0=7fbffffb80 a1=0 a2=ffffffffffffffc0 a3=7 items=1
pid=24388 loginuid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="stress2_test"
exe="/rhcc/eal4/tests/LTP/ltp-full/testcases/audit/stress/stress2_test"
type=PATH msg=audit(1116457159.607:12637634): item=0 name="stress2_dir" inode=5111949 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00
Start of audit.log.2:
type=PATH msg=audit(1116457158.064:12321219): item=0 name="stress1_dir" inode=5111949 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00
type=SYSCALL msg=audit(1116457158.064:12321219): syscall=83 arch=c000003e success=yes exit=0 a0=7fbffffbe0 a1=1ff a2=402136 a3=0 items=1 pid=24343
loginuid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="stress1_test"
exe="/rhcc/eal4/tests/LTP/ltp-full/testcases/audit/stress/stress1_test"
type=PATH msg=audit(1116457158.064:12321233): item=0 name="stress1_dir" inode=5111963 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00
Start of audit.log:
type=SYSCALL msg=audit(1116457159.607:12637634): syscall=84 arch=c000003e success=no exit=-2 a0=7fbffffb80 a1=2 a2=ffffffffffffffc0
a3=5f32737365727473 items=1 pid=24388 loginuid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="stress2_test"
exe="/rhcc/eal4/tests/LTP/ltp-full/testcases/audit/stress/stress2_test"
I was expecting the SYSCALL line for (1116457159.607:12637634) at the start
of audit.log.2,
but it is at the start of audit.log. Can you explain the rotation order to
me? Thanks!
Kris Wilson
Linux Security
(512) 838-0126 T/L:678-0126
krisw(a)us.ibm.com
21 years
Re: key in syscall audit rules.
by Casey Schaufler
--- Klaus Weidner <klaus(a)atsec.com> wrote:
> On Wed, May 18, 2005 at 05:01:50PM +0100, David
> Woodhouse wrote:
> > It doesn't actually need to be mapped by auditd
> before it hits the log.
> > Storing it as-is in the log probably makes more
> sense.
>
> Storing only numbers makes it very hard to interpret
> older log entries;
> the mapping table can potentially change at any
> time, and there's no sane
> way to track the history of all changes to watches
> to do that.
All unix kernel audit trails emit binary data.
Mapping to human friendly forms is left to the
analysis applications. Note however that unix
systems are not expected to change at the same
pace that Linux currently achieves. Also note
that the applications, libraries, and kernel are
maintained as a single entity, and kernel changes
that might louse up the applications are
controlled to prevent such issues.
> I don't object to storing only numbers in the kernel
> and mapping in
> userspace, but the mapping back to strings would
> need to happen before
> they end up in the log.
We've hashed the notion of intellegence in audit
daemons before, and the danger that mapping in
real time will fail remains, especially
in today's sophisticated name service environment.
Syscall numbers are something that can be
staticly mapped into strings, at the expense
of increased record size, and as it's a simple
mapping an audit daemon is not going to be
greatly impacted.
An alternative is to record the mapping in the
audit file header. This is bad if you use lots
of small audit files, but can be done in user
space once during collection and used during
interpretation. Unless you're changing system
call number dynamically, in which case I suggest
you go lie down for a bit until you feel better.
Casey Schaufler
casey(a)schaufler-ca.com
__________________________________
Yahoo! Mail Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
http://mobile.yahoo.com/learn/mail
21 years
audit.41 kernel
by David Woodhouse
* Tue May 17 2005 David Woodhouse <dwmw2(a)redhat.com> audit.41
- Send audit messages from a kernel thread
- Fix d_delete() deadlock with audit_dentry_unpin()
* Tue May 17 2005 David Woodhouse <dwmw2(a)redhat.com> audit.40
- Deal with entire range of userspace messages identically
- Add key to syscall audit rules.
* Tue May 17 2005 David Woodhouse <dwmw2(a)redhat.com> audit.39
- Fix the memory corruption which was my fault.
- Re-enable the auditfs patch which wasn't to blame at all.
- Re-enable S390
* Mon May 16 2005 David Woodhouse <dwmw2(a)redhat.com> audit.38
- Disable the auditfs patch because it doesn't even boot.
- Disable S390 again due to build system failure
* Mon May 16 2005 David Woodhouse <dwmw2(a)redhat.com> audit.37
- Audit socketcall arguments and sockaddrs copied from userspace
- Re-enable SMP and hugemem kernels
* Fri May 13 2005 David Woodhouse <dwmw2(a)redhat.com> audit.36
- Auditfs #7U5a
- Steve's patch logging untrusted strings, more types
--
dwmw2
21 years
User Audit question
by Chad Hanson
Hi,
Currently what is the expected behavior of non-setuid root applications
which utilize the PAM framework? We were doing some testing with newrole
(non-setuid root) which uses PAM for authentication but fails to audit
(unless you are root) authentication records due to lack of audit
capabilities. Newrole succeeds normally without being setuid because
password checking happens via a setuid helper. Is there an idea of such a
helper for the PAM audit framework? Or should newrole be a setuid root
application?
I apologize if this has been covered previously. Also this was using the FC4
T3 kernel and PAM.
Thanks,
-Chad
_______________________________________
Chad Hanson
Manager, Trusted Operating Systems Lab
Trusted Computer Solutions
121 W Goose Alley
Urbana, IL 61801
www.TrustedCS.com
V: 217.384.0028 ext 12
F: 217.384.0288
E: chanson(a)TrustedCS.com
21 years
