On Wednesday, April 7, 2021 3:20:22 AM EDT MAUPERTUIS, PHILIPPE wrote:
> I understand that daemons started by systemd have a uid -1.
> For a specific daemon, I would like to have a different auid to trace what
> the daemon is doing. By having a distinct auid it would be monitored
Hello,
I understand that daemons started by systemd have a uid -1.
For a specific daemon, I would like to have a different auid to trace what the
daemon is doing.
By having a distinct auid it would be monitored without specific rules.
Is that possible ?
Otherwise what would be the best way to
11:29 AM, Steve Grubb wrote:
>
> On Thursday, July 30, 2020 1:54:09 PM EDT Todd Heberlein wrote:
>> I’ve noticed that the httpd process on a CentOS 7.7 system I am working
>> with is running with an Audit ID of -1. Example ID values are:
>>
>>auid=429496
I’ve noticed that the httpd process on a CentOS 7.7 system I am working with is
running with an Audit ID of -1. Example ID values are:
auid=4294967295
uid=48
gid=48
...
So if use the standard filter "-F auid!=-1” in the audit rules I do not see
httpd act
alate. You might be
able to detect them making it executable:
-a exit,always -F arch=b64 -S chmod,fchmod -F dir=/home -F a1&0111 -F
filetype=file -F auid>=1000 -F auid!=-1 -F key=ids-mkexec
-a exit,always -F arch=b64 -S fchmodat -F dir=/home -F a2&0111 -F filetype=file
-F auid>=
On Thursday, July 30, 2020 1:54:09 PM EDT Todd Heberlein wrote:
> I’ve noticed that the httpd process on a CentOS 7.7 system I am working
> with is running with an Audit ID of -1. Example ID values are:
>
> auid=4294967295
> uid=48
> gid=48
> .
On Friday, May 3, 2019 3:31:39 PM EDT Joshua Ammons wrote:
> Hello, I just wanted to see if anyone has had much success with configuring
> redhat systems to reduce and/or eliminate the occurrence of auid = unset
> in the audit events?
auid = unset is a natural thing. Typically it indicat
Hello, I just wanted to see if anyone has had much success with configuring
redhat systems to reduce and/or eliminate the occurrence of auid = unset in the
audit events? I found the following redhat article that provides a fix by
updating a grub setting for auditd but this doesn't seem to
On Monday, February 20, 2017 1:24:28 PM EST Kaptaan wrote:
> Thanks Steve for the prompt response.
>
> Could you please help me understand how the starting of the application from
> systemd will solve my problem of capturing the auid of the person who
> sudoes to another user
Thanks Steve for the prompt response.
Could you please help me understand how the starting of the application from
systemd will solve my problem of capturing the auid of the person who sudoes to
another userid and runs the script to access the files.
sudoes to and runs the script to access
lly executed by the application's daemon process.
>
> The auid shown in the audit logs is always my id for all audit
> events.
Yes. This sounds like a problem. The auid is the mechanism to track who the
person is no matter who they sudo/su to. The uid is the transient id of the
u
. I sudo to and start
the application.
The application starts a few daemon process owned by .
User2 - uses the application to access the files (through some script). The
script is actually executed by the application's daemon process.
The auid shown in the audit logs is always my id fo
@redhat.com
Subject: RE: Why exclude unset auid in STIG rules
> -Original Message-
> From: Steve Grubb [mailto:sgr...@redhat.com]
> Sent: Wednesday, May 11, 2016 12:11 PM
>
> On Wednesday, May 11, 2016 06:40:52 PM Wyatt, Curtis wrote:
> > Ok, so the assumption is
> -Original Message-
> From: Steve Grubb [mailto:sgr...@redhat.com]
> Sent: Wednesday, May 11, 2016 12:11 PM
>
> On Wednesday, May 11, 2016 06:40:52 PM Wyatt, Curtis wrote:
> > Ok, so the assumption is that daemons are not compromised?
>
> This is a complicated topic. Basically there are
x27;t see anything in the SRG that leans towards IDS-like rules. Do you see
any?
-Steve
> -Original Message-
> From: Steve Grubb [mailto:sgr...@redhat.com]
> Sent: Wednesday, May 11, 2016 11:35 AM
>
> When a user logs in, the auid gets set to the uid that they used to login
&
6 11:35 AM
When a user logs in, the auid gets set to the uid that they used to login with.
Daemons are not user sessions and have the loginuid set to -1. The auid
representation is an unsigned 32 bit integer. So, -1 becomes 4294967295. The
rules use a directive like this: -F auid>=1000 to tr
On Wednesday, May 11, 2016 06:28:11 PM Wyatt, Curtis wrote:
> I don't understand why the STIG audit rules have -F auid!=4294967295 in it.
> If auid is unset, why wouldn't you still want to see the events in the
> logs?
When a user logs in, the auid gets set to the uid that
I don't understand why the STIG audit rules have -F auid!=4294967295 in it. If
auid is unset, why wouldn't you still want to see the events in the logs?
Curtis
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
t,never -F subj_type=crond_t
# audit root actions from users switching to root
-a always,exit -F arch=x86_64 -S execve -F auid>=500 -F auid!=-1 -F uid=0
-k root-commands
-a always,exit -F arch=i386 -S execve -F auid>=500 -F auid!=-1 -F uid=0 -k
root-commands
# audit root actions with loginui
from script are fine for me.
OK.
> I altered my audit.rules as you suggested to the following, no other rules:
> auditctl -l:
You can add a key to this if you like, -F key=root-commands
> -a always,exit -F arch=x86_64 -S execve -F auid>=500 -F auid!=-1 -F uid=0
> -a always,exit -F
other rules:
auditctl -l:
-a always,exit -F arch=x86_64 -S execve -F auid>=500 -F auid!=-1 -F uid=0
-a always,exit -F arch=i386 -S execve -F auid>=500 -F auid!=-1 -F uid=0
I get entries from crond like the following in audit.log:
type=USER_ACCT msg=audit(1447855321.729:306): user pid=25780
On Tuesday, November 17, 2015 10:38:17 AM ocakan wrote:
> My aim is to audit only commands executed by root (interactively) and avc
> denied messages (selinux)
I have some questions to help clarify. Command executed by root, or the root
user? Root is uid = 0, Root user is uid = 0 &&am
:
-a never,exit -S all -F auid!=-1
-a never,exit -S all -F auid!=0 -F auid<500
-a always,exit -F arch=x86_64 -S execve -F euid=0 -F key=root-commands
-a always,exit -F arch=i386 -S execve -F euid=0 -F key=root-commands
-a always,exclude -F msgtype=CWD
### auditctl -s:
AUDIT_STATUS: enabled=1 fla
On Monday, August 03, 2015 02:53:52 PM rsh...@umbc.edu wrote:
> > On Monday, August 03, 2015 02:11:31 PM rsh...@umbc.edu wrote:
> >> Comparing the "official" STIG content with the scap-security-guide
> >> content, the former seems to have added corresponding rule
> On Monday, August 03, 2015 02:11:31 PM rsh...@umbc.edu wrote:
>> Comparing the "official" STIG content with the scap-security-guide
>> content, the former seems to have added corresponding rules for "-F
>> auid=0" that aren't present in scap-secu
On Monday, August 03, 2015 02:11:31 PM rsh...@umbc.edu wrote:
> Comparing the "official" STIG content with the scap-security-guide
> content, the former seems to have added corresponding rules for "-F
> auid=0" that aren't present in scap-security guide. i.e. whe
Comparing the "official" STIG content with the scap-security-guide
content, the former seems to have added corresponding rules for "-F
auid=0" that aren't present in scap-security guide. i.e. where
scap-security-guide will just have one rule:
-a always,exit -F arch=ARCH
Thank you !
I think you point the "missing". My first try was on debian wheezy. Now I
try on debian jessie. With jessie, all requirements seems presents and the
field auid has the right value !
type=SYSCALL msg=audit(1430989253.292:23716): arch=c03e syscall=59
success=yes exit=0 a0
On Wed, 2015-05-06 at 10:56 -0400, Steve Grubb wrote:
> Hello,
>
> On Wednesday, May 06, 2015 04:39:16 PM Guillaume L. wrote:
> > I'm trying to use auditd to log all actions made by the users on the
> > system. This part works fine.
> >
> > The documentatio
Hello,
On Wednesday, May 06, 2015 04:39:16 PM Guillaume L. wrote:
> I'm trying to use auditd to log all actions made by the users on the
> system. This part works fine.
>
> The documentation mention the "auid" field to identify the user from the
> first connection &
Bonjour,
I'm trying to use auditd to log all actions made by the users on the
system. This part works fine.
The documentation mention the "auid" field to identify the user from the
first connection "even" when the user's identity changes (like with a su):
auid=
On Monday, January 12, 2015 12:12:02 PM Burak Gürer wrote:
> we have some linux servers and a central log collector system. we are
> sending audit logs to this log system. this log collector system can
> parse such logs but this system confused at lines with "auid=4294967295&qu
and a central log collector system. we are
sending audit logs to this log system. this log collector system can
parse such logs but this system confused at lines with "auid=4294967295"
in audit logs.
i have tried everything but still this lines are coming:
type=USER_ACCT
On Friday, November 14, 2014 10:16:12 AM David Flatley wrote:
>While checking audit logs for failed logins, It was noticed that the
> AUID was one name and there was a UID of the user that failed login. The
> only thing we can figure is that the AUID user rebooted the system
> by l
While checking audit logs for failed logins, It was noticed that the
AUID was one name and there was a UID of the user that failed login. The
only thing we can figure is that the AUID user rebooted the system
by logging in as himself and then using sudo to reboot the system prior to
the fails
On Tuesday, June 03, 2014 01:28:40 PM Briane Lin wrote:
> We are unable to properly monitor an event with AUID=unset, does anyone
> know why we are currently seeing these and what is the resolution?
If you have an unset auid and its supposed to be meaningful, then the way that
peop
We are receiving LINUX RHEL versions 5 and 6 in our environment with
type=SYSCALL and auid=unset event types.
We are unable to properly monitor an event with AUID=unset, does anyone
know why we are currently seeing these and what is the resolution?
Thanks!
Briane Lin
IBM Global Technology
On Tuesday, October 29, 2013 03:39:35 PM leam hall wrote:
> I'm trying to find a definition of "auid", besides "audit UID". If user Joe
> with UID 1814 logs in and sudo to application account "british" which has a
> UID of 1776, is the auid of Joe
James, thanks! I thought that was it, but I have to brief on recommended
audit.rules changes and hate telling someone something when I'm not sure.
Leam
On Tue, Oct 29, 2013 at 3:43 PM, CHAPLIN, JAMES (CTR) <
james.chap...@cbp.dhs.gov> wrote:
> His auid will be 1814 and does not
Hey all,
I'm trying to find a definition of "auid", besides "audit UID". If user Joe
with UID 1814 logs in and sudo to application account "british" which has a
UID of 1776, is the auid of Joe's action 1814 or 1776? If someone does an
"su -" to r
It does work on Redhat 6, it was my mistake.
Philippe
-Message d'origine-
De : Maupertuis Philippe
Envoyé : jeudi 10 octobre 2013 09:13
À : linux-audit@redhat.com
Objet : RE: Auditing only when auid and uid differ
Thanks for the quick reply.
Unfortunately, I guess that a newish k
ubb [mailto:sgr...@redhat.com]
Envoyé : mercredi 9 octobre 2013 18:43
À : linux-audit@redhat.com
Cc : Maupertuis Philippe
Objet : Re: Auditing only when auid and uid differ
On Wednesday, October 09, 2013 06:28:49 PM Maupertuis Philippe wrote:
> I want to track what people are doing when then ch
On Wednesday, October 09, 2013 06:28:49 PM Maupertuis Philippe wrote:
> I want to track what people are doing when then change their userid.
> Basically I would like to write :
> -a exit,never -F arch=b32 -S all -F auid=4294967295
> -a exit,never -F arch=b64 -S all -F auid=42949672
I want to track what people are doing when then change their userid.
Basically I would like to write :
-a exit,never -F arch=b32 -S all -F auid=4294967295
-a exit,never -F arch=b64 -S all -F auid=4294967295
-a exit,always -F arch=b32 -S all -F auid>1000 -F uid!=auid -k userchange
-a e
tation ?
>
> thanks a lot
>
>
> On Thu, Jul 25, 2013 at 4:54 PM, Steve Grubb wrote:
>
>> On Thursday, July 25, 2013 03:35:52 PM zhu xiuming wrote:
>> > The problem is, cat /proc/self/loginuid is still 4294967295 if I login.
>> >
>> > However, I do
f I login.
> >
> > However, I do see lots of events the auid is 0. I even see auid change
> > reflect in the event.
> > Like
> >
> > type=LOGIN msg=audit(07/20/2013 17:45:01.502:40221) : login pid=4952
> > uid=root old auid=unset new auid=root
>
> This would b
On Thursday, July 25, 2013 03:35:52 PM zhu xiuming wrote:
> The problem is, cat /proc/self/loginuid is still 4294967295 if I login.
>
> However, I do see lots of events the auid is 0. I even see auid change
> reflect in the event.
> Like
>
> type=LOGIN msg=audit(07/20/20
Thanks.
I removed quiet from gruf.conf and I see from the output at boot.
I do see like
start audit [ok]
The problem is, cat /proc/self/loginuid is still 4294967295 if I login.
However, I do see lots of events the auid is 0. I even see auid change
reflect in the event.
Like
type=LOGIN msg
On Tuesday, July 23, 2013 03:49:31 PM zhu xiuming wrote:
> I read my audit logs.I always see lots of auid values are 4294967295. Even
> when I delete a file, the value is still 4294967295?
In a normal system, there will be some events with 4294967295. These should be
daemons and system
BTW, I put audit=1 to my grub.conf and restarted my host. Still the same
On Tue, Jul 23, 2013 at 3:49 PM, zhu xiuming wrote:
> I read my audit logs.I always see lots of auid values are 4294967295. Even
> when I delete a file, the value is still 4294967295?
> I added pam_loginuid to g
I read my audit logs.I always see lots of auid values are 4294967295. Even
when I delete a file, the value is still 4294967295?
I added pam_loginuid to gdm, login, kdm, sshd, vsftpd. Howver, it is still
the same value?
I wonder what is wrong?
--
Linux-audit mailing list
Linux-audit@redhat.com
ser "system" uid 500
May 27 10:20:36 doma audispd: node=doma type=SYSCALL
msg=audit(1274948436.000:57884): arch=c03e syscall=59 success=yes exit=0
a0=6cf250 a1=6cf730 a2=6cf510 a3=0 items=2 ppid=26772 pid=27006
auid=4294967295 uid=1000 gid=19 euid=1000 suid=1000 fsuid=1000 egid=19
sgid=1
I would like to audit specifically interactive actions taken from the
console ttys (ttyS0,ttyS1,tty-1-6) and I've just discovered the /bin/login
we use here was compiled without PAM libs. So I guess I will not be able to
get auid nor TTY auditing...
By the way is there any way/future w
On Thursday, June 03, 2010 09:55:35 am Jean-Francois Vincent wrote:
> 1 ) Is there any bug with auid always set to 4294967295 ?
You need pam_loginuid added to crond, gdm, login, kdm, sshd, vsftpd, or any
pamified entry point daemon. (but not sudo or su.)
> 2) I've also searched
cf250 a1=6cf730 a2=6cf510 a3=0 items=2 ppid=26772 pid=27006
auid=4294967295 uid=1000 gid=19 euid=1000 suid=1000 fsuid=1000 egid=19
sgid=19 fsgid=19 tty=tty1 comm="date" exe="/bin/date" key=(null)
May 27 10:20:36 doma audispd: node=doma type=EXECVE
msg=audit(1274948436.000:5788
On Monday 17 May 2010 09:32:15 am Konstantin Ryabitsev wrote:
> It mostly does the right thing, except for cases when an admin logs in
> and restarts a service. If it's running a privileged process, that
> process will have an auid of the user that last ran "service foo
> r
rule:
-a always,exit -F arch=b32 -S execve -F uid=0 -F auid>=500 -F
auid!=4294967295 -k privileged
-a always,exit -F arch=b64 -S execve -F uid=0 -F auid>=500 -F
auid!=4294967295 -k privileged
It mostly does the right thing, except for cases when an admin logs in
and restarts a service. If it&
On Sat, 2010-04-17 at 18:26 -0400, Trevor Vaughan wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello all,
>
> In RHEL5.2 auditing worked fine for me auid was set to the user's uid
> and id was set to whatever it happened to be at the time.
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello all,
In RHEL5.2 auditing worked fine for me auid was set to the user's uid
and id was set to whatever it happened to be at the time.
In RHEL5.4 auid got set to the 'anon' value.
In RHEL5.5 auid gets set to '0' but uid
Thanks Steve. That worked. What I don't understand is that it is not in
the system that already worked.
Thanks again,
David A. Kirkwood
>On Thursday 06 December 2007 02:42:30 pm Kirkwood, David A. wrote:
>> The ausearch -m DAEMON_START returns version 1.0.14 for auditd on
both
>> systems. I grep
On Thursday 06 December 2007 02:42:30 pm Kirkwood, David A. wrote:
> The ausearch -m DAEMON_START returns version 1.0.14 for auditd on both
> systems. I grepped for loginuid.so in the pam.d directory and it appears in
> all of the same pam entries on both systems. No luck yet, however I
> appreciat
. I tried to get it by
>pulling strings with no success. The larger problem is I am configuring
>a RHEL4U5 system. I have a RHEL4U4 system that runs correctly and
>supplies the AUID when specified with aureport. The RHEL4U5 system has
>this parameter as "unset" rather than the A
Thanks Klaus,
The ausearch -m DAEMON_START returns version 1.0.14 for auditd on both systems.
I grepped for loginuid.so in the pam.d directory and it appears in all of the
same pam entries on both systems.
No luck yet, however I appreciate your help.
David A. Kirkwood
>>
>> I need some help
> $ audearch -m DAEMON_START
read that as $ausearch -m DAEMON_START
The best option would still be just 'rpm -q audit' and check the output
--
Klaus Heinrich Kiwi/Brazil/IBM <[EMAIL PROTECTED]>
Software Engineer
IBM STG, Linux Technology Center
Phone:(+55-19) 2132-1909 [T/L 839-1909]
--
Linux-
>
> I need some help with configuration. First, I do not remember how to
> tell the version of the auditd I am running. I tried to get it by
> pulling strings with no success.
To identify the audit version you're running, you could use the package
version+release or possibly something like
$ au
Hi,
I need some help with configuration. First, I do not remember how to
tell the version of the auditd I am running. I tried to get it by
pulling strings with no success. The larger problem is I am configuring
a RHEL4U5 system. I have a RHEL4U4 system that runs correctly and
supplies the AUID
AUID when specified with aureport. The
RHEL4U5 system has this parameter as "unset" rather than the
AUID or uid or anything else to identify who was attempting to run
failed commands.
If someone can help me with what needs to be set, I would appreciate it.
I compared all of the obv
he old rule style for communicating with the kernel for
backward compatibility with old kernels - pre-2.6.16) There is slightly newer
RHEL5 audit packages here:
http://people.redhat.com/sgrubb/files/lspp/
But the RHEL5.1 package 1.5.5-5 should work fine:
# auditctl -a exit,always -S open -F
Hello,
I would like some of my audit rules to apply when auid >= 500
For example consider this use case:
[EMAIL PROTECTED] audit]# auditctl -v
auditctl version 1.3.1
[EMAIL PROTECTED] audit]# cat /etc/audit/audit.rules
# This file contains the auditctl rules that are loaded
# whenever
On Sun, 2007-02-25 at 18:17 -0500, Steve Grubb wrote:
> On Tuesday 20 February 2007 16:29:25 Matthew Booth wrote:
> > I needed a way to exclude a very large class of audit traffic [1] in
> > RHEL 4. It occurred to me that if I could launch a process and give it
> > the auid o
On Tuesday 20 February 2007 16:29:25 Matthew Booth wrote:
> I needed a way to exclude a very large class of audit traffic [1] in
> RHEL 4. It occurred to me that if I could launch a process and give it
> the auid of a dedicated user, I could easily filter it out along with
> all chi
I needed a way to exclude a very large class of audit traffic [1] in
RHEL 4. It occurred to me that if I could launch a process and give it
the auid of a dedicated user, I could easily filter it out along with
all child processes. With this in mind I wrote the attached simple
wrapper round the
Are you sure you have pam_loginuid.so configured in the appropriate
/etc/pam.d/* files, such as login and sshd?
I checked the login file and it matches yours, I am not using ssh on
this machine.
I'm running the .41 kernel and the audit-1.2.4 tools and
the auid is correct in the
Are you sure you have pam_loginuid.so configured in the appropriate
/etc/pam.d/* files, such as login and sshd?
I'm running the .41 kernel and the audit-1.2.4 tools and
the auid is correct in the audit records on my system.
This is what my /etc/pam.d/login file looks like:
#%PAM-1.0
I am receiving audit events with an odd auid... I am not sure if this
is something wrong in the kernel or in audit. The auid I am receiving
is 4294967295 (the max value for an unsigned long). The other uid/gid
information is normal.
I have seen this on all audit versions since audit-1.2.3
75 matches
Mail list logo
