January 2010 - Linux-audit - Linux-Audit List Archives

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

12 years, 4 months

5
17
0 / 0

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

13 years, 7 months

3
4
0 / 0

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

13 years, 7 months

4
11
0 / 0

ausearch

by Pittigher, Raymond - CS

I see that the -w or --word switch was added to the ausearch but how it it used? The man pages claim: String based matches must match the whole word. But I have been trying ausearch -w failed and variation of that but only get the message ausearch -if audit.log.3 -w failed failed is an unsupported option This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail.

15 years, 2 months

3
2
0 / 0

Gavin Appleton is out of the office.

by Gavin Appleton

I will be out of the office starting 28/01/2010 and will not return until 05/02/2010. I will respond to your message when I return.

16 years

1
0
0 / 0

nispom.rules for RHEL WS 4

by Harmon, Jeffrey D

To all, Is there a version of nispom.rules that will work with "Audit-1.0.16" on RHEL WS 4?? Tried moving working nispom.rules file from Centos 5 running audit-1.7.7 but auditd fails at startup with error: "filter key option needs a watch given prior to it" Jeff Harmon IT Manager / Senior Network Administrator / FSO Alion Science and Technology Advanced Modeling and Simulation Technology Operation (AMSTO) 2602 Challenger Tech Court, Suite 230 Orlando, FL 32826 Tel: (407) 737-3599 x404 Fax: (407) 737-0847 Cell: (407) 353-7238 jharmon(a)alionscience.com www.alionscience.com <http://www.alionscience.com/>

16 years

2
1
0 / 0

How to learn the Message type?

by 陈洁丹

Hello, my friends. Every record contains a type field.It's about the message type such as AUDIT_AVC, AUDIT_SYSCALL and so on. Does AVC mean Mandatory Access Control ? Is all the messag types listed in msg_typetab.h? What do they mean exactly? Where can I get the information about them ? I look into the _LIBAUDIT_H_ , and find this sentence * 1300 - 1399 audit event messages But in this file , I find nothing about audit event message Can anyone give me an URL or give a book for me about the audit event message? Thanks a lot ^_^ Jeedan -- ----------------------------- 陈洁丹北京邮电大学软件学院地址：北京邮电大学学二D12寝室邮编： 100876 Email: jeedan.chen(a)gmail.com ---------------------------------

16 years

3
6
0 / 0

Re: How do I figure out on what file dac_override is attempted?

by Daniel J Walsh

On 01/20/2010 11:15 AM, Joshua Brindle wrote: > Stephen Smalley wrote: >> On Wed, 2010-01-20 at 10:12 -0500, Daniel J Walsh wrote: >>> On 01/20/2010 08:51 AM, Stephen Smalley wrote: >>>> On Wed, 2010-01-20 at 13:47 +0100, Göran Uddeborg wrote: >>>>> Stephen Smalley: >>>>>> To get object information, you need to enable >>>>>> syscall auditing, and add a trivial syscall filter to turn on >>>>>> pathname >>>>>> collection by the audit subsystem. >>>>> Thanks for that tip (all of you who gave it)! I now know it is >>>>> /dev/fb that plymouthd can't access. The audit record also told me it >>>>> was owned by a regular user and mode rw-------. So now it makes >>>>> sense. A root process would need dac_override to open that file. >>>> That tip really ought to get captured in the Fedora SELinux FAQ or >>>> Guide. Dan? >>>> >>> You mean turning on full auditing if you have a suspicious DAC_OVERRIDE? >> >> More generally, if you want full pathname information for an AVC denial >> and you aren't getting it in the AVC message, you can get it by adding a >> trivial audit syscall filter and re-trying the operation, where adding a >> trivial audit syscall filter can be done by any of the three examples >> given by Steve Grubb, Eric, or myself - take your pick. It can be done >> temporarily just by running auditctl or on every boot by adding the >> entry to /etc/audit/audit.rules. >> > > Can we add it to selinuxproject.org instead (or in addition to, I guess?) Here is my blog on it. http://danwalsh.livejournal.com/34903.html

16 years

3
4
0 / 0

Re: How do I figure out on what file dac_override is attempted?

by Stephen Smalley

On Wed, 2010-01-20 at 13:47 +0100, Göran Uddeborg wrote: > Stephen Smalley: > > To get object information, you need to enable > > syscall auditing, and add a trivial syscall filter to turn on pathname > > collection by the audit subsystem. > > Thanks for that tip (all of you who gave it)! I now know it is > /dev/fb that plymouthd can't access. The audit record also told me it > was owned by a regular user and mode rw-------. So now it makes > sense. A root process would need dac_override to open that file. That tip really ought to get captured in the Fedora SELinux FAQ or Guide. Dan? -- Stephen Smalley National Security Agency

16 years

2
2
0 / 0

Re: How do I figure out on what file dac_override is attempted?

by Stephen Smalley

On Mon, 2010-01-18 at 22:05 +0100, Göran Uddeborg wrote: > Here is another strange AVC I'm trying to understand. > > SETroubleshoot on one of my machines is telling me that > > SELinux is preventing plymouthd (plymouthd_t) "dac_override" plymouthd_t. > > The full message is attached. > > If I have understood this correctly, this means that plymouthd was > trying to read a file as root. But the regular permissions bits of > the file would not allow that. (Right?) > > I assume there is some file with wrong permission bits, which causes > this to happen. But I can't find any indication WHAT file it was. > Looking at the message, it seems to me it was trying a dac_override on > itself. > > Is there a way to know what file was involved? The capability checks in Linux do not pass the object to the security module, so SELinux only knows about the current task and the particular capability requested. To get object information, you need to enable syscall auditing, and add a trivial syscall filter to turn on pathname collection by the audit subsystem. Then re-try the operation that generated the denial. auditctl -s will show the current status of the audit system. auditctl -a exit,always -S chroot is an example syscall filter. The filter doesn't need to have anything to do with your failing operation - it just turns on the machinery that will cause pathname collection so that when the AVC is generated, you will also get a SYSCALL record with the pathname info. -- Stephen Smalley National Security Agency

16 years

2
2
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Linux-audit January 2010