* Is audit=1 still required for RHEL 7? @ 2015-01-06 18:54 Erinn Looney-Triggs 2015-01-06 19:13 ` Steve Grubb 0 siblings, 1 reply; 14+ messages in thread From: Erinn Looney-Triggs @ 2015-01-06 18:54 UTC (permalink / raw) To: linux-audit [-- Attachment #1.1: Type: text/plain, Size: 221 bytes --] I have been digging around trying to find the answer to the above, hopefully I didn't miss something obvious. It was for RHEL < 7 is it still for RHEL 7? Or has systemd done some magic to remove that need? -Erinn [-- Attachment #1.2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 473 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Is audit=1 still required for RHEL 7? 2015-01-06 18:54 Is audit=1 still required for RHEL 7? Erinn Looney-Triggs @ 2015-01-06 19:13 ` Steve Grubb 2015-01-06 19:16 ` Erinn Looney-Triggs 0 siblings, 1 reply; 14+ messages in thread From: Steve Grubb @ 2015-01-06 19:13 UTC (permalink / raw) To: linux-audit; +Cc: Erinn Looney-Triggs On Tuesday, January 06, 2015 11:54:37 AM Erinn Looney-Triggs wrote: > I have been digging around trying to find the answer to the above, hopefully > I didn't miss something obvious. It was for RHEL < 7 is it still for RHEL > 7? Or has systemd done some magic to remove that need? AFAIK, all linux kernels from all distributions have the same need. What that flag does is enable the audit system. When the audit system is enabled and every time there is a fork, the TIF_AUDIT flag is added to the process. This make the process auditable. Without this flag, the process cannot be audited...ever. So, if systemd was to do some magic (and it doesn't), then systemd itself would not be auditable nor any process it creates until audit became enabled. -Steve ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Is audit=1 still required for RHEL 7? 2015-01-06 19:13 ` Steve Grubb @ 2015-01-06 19:16 ` Erinn Looney-Triggs 2015-01-08 10:12 ` Burak Gürer 0 siblings, 1 reply; 14+ messages in thread From: Erinn Looney-Triggs @ 2015-01-06 19:16 UTC (permalink / raw) To: Steve Grubb; +Cc: linux-audit [-- Attachment #1.1: Type: text/plain, Size: 1034 bytes --] On Tuesday, January 06, 2015 02:13:27 PM Steve Grubb wrote: > On Tuesday, January 06, 2015 11:54:37 AM Erinn Looney-Triggs wrote: > > I have been digging around trying to find the answer to the above, > > hopefully I didn't miss something obvious. It was for RHEL < 7 is it > > still for RHEL 7? Or has systemd done some magic to remove that need? > > AFAIK, all linux kernels from all distributions have the same need. What > that flag does is enable the audit system. When the audit system is enabled > and every time there is a fork, the TIF_AUDIT flag is added to the process. > This make the process auditable. > > Without this flag, the process cannot be audited...ever. So, if systemd was > to do some magic (and it doesn't), then systemd itself would not be > auditable nor any process it creates until audit became enabled. > > -Steve Thanks Steve, I just wanted to check, I couldn't find anything explicitly mentioning this. I think I'll open a bug for the SCAP security guide about this. -Erinn [-- Attachment #1.2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 473 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Is audit=1 still required for RHEL 7? 2015-01-06 19:16 ` Erinn Looney-Triggs @ 2015-01-08 10:12 ` Burak Gürer 2015-01-08 13:03 ` Steve Grubb 0 siblings, 1 reply; 14+ messages in thread From: Burak Gürer @ 2015-01-08 10:12 UTC (permalink / raw) To: Erinn Looney-Triggs, Steve Grubb; +Cc: linux-audit [-- Attachment #1.1: Type: text/plain, Size: 1839 bytes --] Hi everyone! first of all sorry for my bad english! i could not accomplish to get rid of from auid=4294967295 issue i have implemented that suggestions: https://www.redhat.com/archives/linux-audit/2010-June/msg00002.html https://people.redhat.com/sgrubb/audit/audit-faq.txt but not succeed. is there any other reasons or solutions? by the way suggestions in the links, is it important to where we put the suggested confs: e.g. which line to put "audit=1" or which line to put "session required pam_loginuid.so" and further are kernel or audit package versions important? If anyone can help with this it will be very helpful. Regards, On 06-01-2015 21:16, Erinn Looney-Triggs wrote: > On Tuesday, January 06, 2015 02:13:27 PM Steve Grubb wrote: >> On Tuesday, January 06, 2015 11:54:37 AM Erinn Looney-Triggs wrote: >>> I have been digging around trying to find the answer to the above, >>> hopefully I didn't miss something obvious. It was for RHEL < 7 is it >>> still for RHEL 7? Or has systemd done some magic to remove that need? >> AFAIK, all linux kernels from all distributions have the same need. What >> that flag does is enable the audit system. When the audit system is enabled >> and every time there is a fork, the TIF_AUDIT flag is added to the process. >> This make the process auditable. >> >> Without this flag, the process cannot be audited...ever. So, if systemd was >> to do some magic (and it doesn't), then systemd itself would not be >> auditable nor any process it creates until audit became enabled. >> >> -Steve > Thanks Steve, I just wanted to check, I couldn't find anything explicitly > mentioning this. I think I'll open a bug for the SCAP security guide about > this. > > -Erinn > > > -- > Linux-audit mailing list > Linux-audit@redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit [-- Attachment #1.2: Type: text/html, Size: 3163 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Is audit=1 still required for RHEL 7? 2015-01-08 10:12 ` Burak Gürer @ 2015-01-08 13:03 ` Steve Grubb 2015-01-08 13:33 ` Burak Gürer 2015-01-08 16:39 ` Audit rotate David Flatley 0 siblings, 2 replies; 14+ messages in thread From: Steve Grubb @ 2015-01-08 13:03 UTC (permalink / raw) To: burak4burak, linux-audit On Thursday, January 08, 2015 12:12:14 PM Burak Gürer wrote: > Hi everyone! > > first of all sorry for my bad english! > > i could not accomplish to get rid of from auid=4294967295 issue > > i have implemented that suggestions: > > https://www.redhat.com/archives/linux-audit/2010-June/msg00002.html > https://people.redhat.com/sgrubb/audit/audit-faq.txt > > but not succeed. > is there any other reasons or solutions? There is a chance that --with-audit or --enable-audit was not used in the configuration of the utilities. I can't say for certain without knowing more about your distribution. > by the way suggestions in the links, is it important to where we put the > suggested confs: > > e.g. which line to put "audit=1" That is a kernel boot parameter. > or which line to put "session required pam_loginuid.so" This would go into the pam configuration of system entry points. For example, it would be in /etc/pam.d/login. But it would NOT go into /etc/pam.d/system- auth or /etc/pam.d/su. This should already be configured by your distribution and you shouldn't need to adjust it. > and further are kernel or audit package versions important? Yes. But not to the two questions you ask above. More important is whether or not auditing is enabled in the packages by your distribution. The audit facilities from your question has been available almost 10 years. So, I wonder if auditing is enabled. -Steve > If anyone can help with this it will be very helpful. > > Regards, > > On 06-01-2015 21:16, Erinn Looney-Triggs wrote: > > On Tuesday, January 06, 2015 02:13:27 PM Steve Grubb wrote: > >> On Tuesday, January 06, 2015 11:54:37 AM Erinn Looney-Triggs wrote: > >>> I have been digging around trying to find the answer to the above, > >>> hopefully I didn't miss something obvious. It was for RHEL < 7 is it > >>> still for RHEL 7? Or has systemd done some magic to remove that need? > >> > >> AFAIK, all linux kernels from all distributions have the same need. What > >> that flag does is enable the audit system. When the audit system is > >> enabled > >> and every time there is a fork, the TIF_AUDIT flag is added to the > >> process. > >> This make the process auditable. > >> > >> Without this flag, the process cannot be audited...ever. So, if systemd > >> was > >> to do some magic (and it doesn't), then systemd itself would not be > >> auditable nor any process it creates until audit became enabled. > >> > >> -Steve > > > > Thanks Steve, I just wanted to check, I couldn't find anything explicitly > > mentioning this. I think I'll open a bug for the SCAP security guide about > > this. > > > > -Erinn > > > > > > -- > > Linux-audit mailing list > > Linux-audit@redhat.com > > https://www.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Is audit=1 still required for RHEL 7? 2015-01-08 13:03 ` Steve Grubb @ 2015-01-08 13:33 ` Burak Gürer 2015-01-08 14:13 ` Steve Grubb 2015-01-08 16:39 ` Audit rotate David Flatley 1 sibling, 1 reply; 14+ messages in thread From: Burak Gürer @ 2015-01-08 13:33 UTC (permalink / raw) To: Steve Grubb, linux-audit [-- Attachment #1.1: Type: text/plain, Size: 3941 bytes --] On 08-01-2015 15:03, Steve Grubb wrote: > On Thursday, January 08, 2015 12:12:14 PM Burak Gürer wrote: >> Hi everyone! >> >> first of all sorry for my bad english! >> >> i could not accomplish to get rid of from auid=4294967295 issue >> >> i have implemented that suggestions: >> >> https://www.redhat.com/archives/linux-audit/2010-June/msg00002.html >> https://people.redhat.com/sgrubb/audit/audit-faq.txt >> >> but not succeed. >> is there any other reasons or solutions? > There is a chance that --with-audit or --enable-audit was not used in the > configuration of the utilities. I can't say for certain without knowing more > about your distribution. distrubution is: [root@test /root]# lsb_release -a LSB Version: :core-3.1-amd64:core-3.1-ia32:core-3.1-noarch:graphics-3.1-amd64:graphics-3.1-ia32:graphics-3.1-noarch Distributor ID: RedHatEnterpriseServer Description: Red Hat Enterprise Linux Server release 5.2 (Tikanga) Release: 5.2 Codename: Tikanga >> by the way suggestions in the links, is it important to where we put the >> suggested confs: >> >> e.g. which line to put "audit=1" > That is a kernel boot parameter. is this correct?: # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/sda2 # initrd /initrd-version.img #boot=/dev/sda default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title Red Hat Enterprise Linux Server (2.6.18-92.el5) root (hd0,0) kernel /vmlinuz-2.6.18-92.el5 ro root=LABEL=/ *audit=1* rhgb quiet initrd /initrd-2.6.18-92.el5.img >> or which line to put "session required pam_loginuid.so" > This would go into the pam configuration of system entry points. For example, > it would be in /etc/pam.d/login. But it would NOT go into /etc/pam.d/system- > auth or /etc/pam.d/su. This should already be configured by your distribution > and you shouldn't need to adjust it. > >> and further are kernel or audit package versions important? > Yes. But not to the two questions you ask above. More important is whether or > not auditing is enabled in the packages by your distribution. The audit > facilities from your question has been available almost 10 years. So, I wonder > if auditing is enabled. so how can i check if auditing is enabled? > > -Steve > >> If anyone can help with this it will be very helpful. >> >> Regards, >> >> On 06-01-2015 21:16, Erinn Looney-Triggs wrote: >>> On Tuesday, January 06, 2015 02:13:27 PM Steve Grubb wrote: >>>> On Tuesday, January 06, 2015 11:54:37 AM Erinn Looney-Triggs wrote: >>>>> I have been digging around trying to find the answer to the above, >>>>> hopefully I didn't miss something obvious. It was for RHEL < 7 is it >>>>> still for RHEL 7? Or has systemd done some magic to remove that need? >>>> AFAIK, all linux kernels from all distributions have the same need. What >>>> that flag does is enable the audit system. When the audit system is >>>> enabled >>>> and every time there is a fork, the TIF_AUDIT flag is added to the >>>> process. >>>> This make the process auditable. >>>> >>>> Without this flag, the process cannot be audited...ever. So, if systemd >>>> was >>>> to do some magic (and it doesn't), then systemd itself would not be >>>> auditable nor any process it creates until audit became enabled. >>>> >>>> -Steve >>> Thanks Steve, I just wanted to check, I couldn't find anything explicitly >>> mentioning this. I think I'll open a bug for the SCAP security guide about >>> this. >>> >>> -Erinn >>> >>> >>> -- >>> Linux-audit mailing list >>> Linux-audit@redhat.com >>> https://www.redhat.com/mailman/listinfo/linux-audit [-- Attachment #1.2: Type: text/html, Size: 5953 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Is audit=1 still required for RHEL 7? 2015-01-08 13:33 ` Burak Gürer @ 2015-01-08 14:13 ` Steve Grubb 2015-01-12 10:12 ` auid=4294967295 issue Burak Gürer 0 siblings, 1 reply; 14+ messages in thread From: Steve Grubb @ 2015-01-08 14:13 UTC (permalink / raw) To: burak4burak; +Cc: linux-audit Hello, On Thursday, January 08, 2015 03:33:08 PM Burak Gürer wrote: > On 08-01-2015 15:03, Steve Grubb wrote: > > On Thursday, January 08, 2015 12:12:14 PM Burak Gürer wrote: > >> Hi everyone! > >> > >> first of all sorry for my bad english! > >> > >> i could not accomplish to get rid of from auid=4294967295 issue > >> > >> i have implemented that suggestions: > >> > >> https://www.redhat.com/archives/linux-audit/2010-June/msg00002.html > >> https://people.redhat.com/sgrubb/audit/audit-faq.txt > >> > >> but not succeed. > >> is there any other reasons or solutions? > > > > There is a chance that --with-audit or --enable-audit was not used in the > > configuration of the utilities. I can't say for certain without knowing > > more about your distribution. > > distrubution is: > > [root@test /root]# lsb_release -a > > LSB Version: > :core-3.1-amd64:core-3.1-ia32:core-3.1-noarch:graphics-3.1-amd64:graphics-3. > :1-ia32:graphics-3.1-noarch > Distributor ID: RedHatEnterpriseServer > Description: Red Hat Enterprise Linux Server release 5.2 (Tikanga) > Release: 5.2 > Codename: Tikanga OK. Then I know that auditing is enabled in everything possible. > >> by the way suggestions in the links, is it important to where we put the > >> suggested confs: > >> > >> e.g. which line to put "audit=1" > > > > That is a kernel boot parameter. > > is this correct?: > > # grub.conf generated by anaconda > # > # Note that you do not have to rerun grub after making changes to this file > # NOTICE: You have a /boot partition. This means that > # all kernel and initrd paths are relative to /boot/, eg. > # root (hd0,0) > # kernel /vmlinuz-version ro root=/dev/sda2 > # initrd /initrd-version.img > #boot=/dev/sda > default=0 > timeout=5 > splashimage=(hd0,0)/grub/splash.xpm.gz > hiddenmenu > title Red Hat Enterprise Linux Server (2.6.18-92.el5) > root (hd0,0) > kernel /vmlinuz-2.6.18-92.el5 ro root=LABEL=/ *audit=1* rhgb quiet Yes, this is correct, assuming that the '*' was added just for emphasis but is absent in the real file. That must be in place for each bootable kernel for it to universally work. > initrd /initrd-2.6.18-92.el5.img > > >> or which line to put "session required pam_loginuid.so" > > > > This would go into the pam configuration of system entry points. For > > example, it would be in /etc/pam.d/login. But it would NOT go into > > /etc/pam.d/system- auth or /etc/pam.d/su. This should already be > > configured by your distribution and you shouldn't need to adjust it. > > > >> and further are kernel or audit package versions important? > > > > Yes. But not to the two questions you ask above. More important is whether > > or not auditing is enabled in the packages by your distribution. The > > audit facilities from your question has been available almost 10 years. > > So, I wonder if auditing is enabled. > > so how can i check if auditing is enabled? For RHEL5, I know its enabled. But based on your questions above, you are asking 2 things. Where to put audit=1 and if pam_loginuid is right. For these, # cat /proc/cmdline and # cat /proc/self/loginuid would let you check. In the first, make sure audit=1 is there and in the second case, the output should be the uid under which you logged into the system. -Steve ^ permalink raw reply [flat|nested] 14+ messages in thread
* auid=4294967295 issue 2015-01-08 14:13 ` Steve Grubb @ 2015-01-12 10:12 ` Burak Gürer 2015-01-12 14:54 ` Steve Grubb 0 siblings, 1 reply; 14+ messages in thread From: Burak Gürer @ 2015-01-12 10:12 UTC (permalink / raw) To: Steve Grubb; +Cc: linux-audit [-- Attachment #1.1: Type: text/plain, Size: 1698 bytes --] Hi Steve, thanks for your assistance, > For RHEL5, I know its enabled. But based on your questions above, you are > asking 2 things. Where to put audit=1 and if pam_loginuid is right. For these, > > # cat /proc/cmdline > > and > > # cat /proc/self/loginuid > > would let you check. In the first, make sure audit=1 is there and in the second > case, the output should be the uid under which you logged into the system. > > -Steve [root@test /root]# cat /proc/cmdline ro root=LABEL=/ audit=1 rhgb quiet [root@test /root]# cat /proc/self/loginuid 0 To narrow the circle; 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" in audit logs. i have tried everything but still this lines are coming: type=USER_ACCT msg=audit(1420656001.965:2804): user pid=6083 uid=0 auid=4294967295 msg='PAM: accounting acct="root" : exe="/usr/sbin/crond" (hostname=?, addr=?, terminal=cron res=success)' type=CRED_ACQ msg=audit(1420656001.966:2805): user pid=6083 uid=0 auid=4294967295 msg='PAM: setcred acct="root" : exe="/usr/sbin/crond" (hostname=?, addr=?, terminal=cron res=success)' and [root@test /root]# cat /etc/pam.d/crond # # The PAM configuration file for the cron daemon # # session required pam_loginuid.so auth required pam_unix.so auth required pam_nologin.so account required pam_unix.so password required pam_unix.so session required pam_unix.so so is there any other hints or what can i do esle? [-- Attachment #1.2: Type: text/html, Size: 2330 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: auid=4294967295 issue 2015-01-12 10:12 ` auid=4294967295 issue Burak Gürer @ 2015-01-12 14:54 ` Steve Grubb 0 siblings, 0 replies; 14+ messages in thread From: Steve Grubb @ 2015-01-12 14:54 UTC (permalink / raw) To: burak4burak; +Cc: linux-audit 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" > in audit logs. auid=4294967295 is the same as auid=-1 which means that its unset. > i have tried everything but still this lines are coming: > > type=USER_ACCT msg=audit(1420656001.965:2804): user pid=6083 uid=0 > auid=4294967295 msg='PAM: accounting acct="root" : > exe="/usr/sbin/crond" (hostname=?, addr=?, terminal=cron res=success)' > type=CRED_ACQ msg=audit(1420656001.966:2805): user pid=6083 uid=0 > auid=4294967295 msg='PAM: setcred acct="root" : > exe="/usr/sbin/crond" (hostname=?, addr=?, terminal=cron res=success)' > > and > > [root@test /root]# cat /etc/pam.d/crond > # > # The PAM configuration file for the cron daemon > # > # > session required pam_loginuid.so > auth required pam_unix.so > auth required pam_nologin.so > account required pam_unix.so > password required pam_unix.so > session required pam_unix.so > > so is there any other hints or what can i do esle? Your pam file looks different than what is shipped. You might want to try the default config file for crond: auth sufficient pam_env.so auth required pam_rootok.so auth include system-auth account required pam_access.so account include system-auth session required pam_loginuid.so session include system-auth -Steve ^ permalink raw reply [flat|nested] 14+ messages in thread
* Audit rotate 2015-01-08 13:03 ` Steve Grubb 2015-01-08 13:33 ` Burak Gürer @ 2015-01-08 16:39 ` David Flatley 2015-01-08 16:46 ` Steve Grubb 1 sibling, 1 reply; 14+ messages in thread From: David Flatley @ 2015-01-08 16:39 UTC (permalink / raw) To: Steve Grubb; +Cc: linux-audit, linux-audit-bounces Trying to setup Auditing on a Suse Server 11 SP3 with audit version 1.8.0.3. Apparently "audit rotate" is not available on this version of auditd? I know from past posts by Steve Grubb that logrotate does not work well rotating /var/log/audit/audit.log. So any thoughts on doing audit logrotations? Thanks David Flatley CISSP "To err is human. To really screw up requires the root password." -UNKNOWN ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Audit rotate 2015-01-08 16:39 ` Audit rotate David Flatley @ 2015-01-08 16:46 ` Steve Grubb 2015-01-08 17:17 ` David Flatley 0 siblings, 1 reply; 14+ messages in thread From: Steve Grubb @ 2015-01-08 16:46 UTC (permalink / raw) To: David Flatley; +Cc: linux-audit On Thursday, January 08, 2015 11:39:17 AM David Flatley wrote: > Trying to setup Auditing on a Suse Server 11 SP3 with audit version > 1.8.0.3. Apparently "audit rotate" is not available on this version of > auditd? I know from past posts by Steve Grubb that logrotate does not > work well rotating /var/log/audit/audit.log. So any thoughts on doing audit > logrotations? "service auditd rotate" is simply a convenience for sending SIGUSR1 to auditd. That is all you need to do to force rotation of the logs. -Steve ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Audit rotate 2015-01-08 16:46 ` Steve Grubb @ 2015-01-08 17:17 ` David Flatley 2015-01-08 17:23 ` Steve Grubb 0 siblings, 1 reply; 14+ messages in thread From: David Flatley @ 2015-01-08 17:17 UTC (permalink / raw) To: Steve Grubb; +Cc: linux-audit I have "/sbin/service auditd rotate" in my scripts I use on my Red Hat systems. But apparently on Suse it does not rotate the logs. When I run the rotate command it comes back with what it can do and rotate is not in there. Oh and it is auditd 1.8.0.30-1. David Flatley CISSP "To err is human. To really screw up requires the root password." -UNKNOWN From: Steve Grubb <sgrubb@redhat.com> To: David Flatley/Burlington/IBM@IBMUS, Cc: linux-audit@redhat.com Date: 01/08/2015 11:46 AM Subject: Re: Audit rotate On Thursday, January 08, 2015 11:39:17 AM David Flatley wrote: > Trying to setup Auditing on a Suse Server 11 SP3 with audit version > 1.8.0.3. Apparently "audit rotate" is not available on this version of > auditd? I know from past posts by Steve Grubb that logrotate does not > work well rotating /var/log/audit/audit.log. So any thoughts on doing audit > logrotations? "service auditd rotate" is simply a convenience for sending SIGUSR1 to auditd. That is all you need to do to force rotation of the logs. -Steve ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Audit rotate 2015-01-08 17:17 ` David Flatley @ 2015-01-08 17:23 ` Steve Grubb 2015-01-08 17:47 ` David Flatley 0 siblings, 1 reply; 14+ messages in thread From: Steve Grubb @ 2015-01-08 17:23 UTC (permalink / raw) To: David Flatley; +Cc: linux-audit On Thursday, January 08, 2015 12:17:40 PM David Flatley wrote: > I have "/sbin/service auditd rotate" in my scripts I use on my Red Hat > systems. But apparently on Suse it does not rotate the logs. When I run the > rotate command it comes back with what it can > do and rotate is not in there. Oh and it is auditd 1.8.0.30-1. What I'm trying to say is that if the init script does not support it, then all you need to do is send sigusr1 to auditd instead. Something like: kill -USR1 `pidof auditd` -Steve > From: Steve Grubb <sgrubb@redhat.com> > To: David Flatley/Burlington/IBM@IBMUS, > Cc: linux-audit@redhat.com > Date: 01/08/2015 11:46 AM > Subject: Re: Audit rotate > > On Thursday, January 08, 2015 11:39:17 AM David Flatley wrote: > > Trying to setup Auditing on a Suse Server 11 SP3 with audit version > > > > 1.8.0.3. Apparently "audit rotate" is not available on this version of > > auditd? I know from past posts by Steve Grubb that logrotate does not > > work well rotating /var/log/audit/audit.log. So any thoughts on doing > > audit > > > logrotations? > > "service auditd rotate" is simply a convenience for sending SIGUSR1 to > auditd. > That is all you need to do to force rotation of the logs. > > -Steve ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Audit rotate 2015-01-08 17:23 ` Steve Grubb @ 2015-01-08 17:47 ` David Flatley 0 siblings, 0 replies; 14+ messages in thread From: David Flatley @ 2015-01-08 17:47 UTC (permalink / raw) To: Steve Grubb; +Cc: linux-audit Yup that did it! Thanks Steve. David Flatley CISSP "To err is human. To really screw up requires the root password." -UNKNOWN From: Steve Grubb <sgrubb@redhat.com> To: David Flatley/Burlington/IBM@IBMUS, Cc: linux-audit@redhat.com Date: 01/08/2015 12:30 PM Subject: Re: Audit rotate On Thursday, January 08, 2015 12:17:40 PM David Flatley wrote: > I have "/sbin/service auditd rotate" in my scripts I use on my Red Hat > systems. But apparently on Suse it does not rotate the logs. When I run the > rotate command it comes back with what it can > do and rotate is not in there. Oh and it is auditd 1.8.0.30-1. What I'm trying to say is that if the init script does not support it, then all you need to do is send sigusr1 to auditd instead. Something like: kill -USR1 `pidof auditd` -Steve > From: Steve Grubb <sgrubb@redhat.com> > To: David Flatley/Burlington/IBM@IBMUS, > Cc: linux-audit@redhat.com > Date: 01/08/2015 11:46 AM > Subject: Re: Audit rotate > > On Thursday, January 08, 2015 11:39:17 AM David Flatley wrote: > > Trying to setup Auditing on a Suse Server 11 SP3 with audit version > > > > 1.8.0.3. Apparently "audit rotate" is not available on this version of > > auditd? I know from past posts by Steve Grubb that logrotate does not > > work well rotating /var/log/audit/audit.log. So any thoughts on doing > > audit > > > logrotations? > > "service auditd rotate" is simply a convenience for sending SIGUSR1 to > auditd. > That is all you need to do to force rotation of the logs. > > -Steve ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2015-01-12 14:54 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-01-06 18:54 Is audit=1 still required for RHEL 7? Erinn Looney-Triggs 2015-01-06 19:13 ` Steve Grubb 2015-01-06 19:16 ` Erinn Looney-Triggs 2015-01-08 10:12 ` Burak Gürer 2015-01-08 13:03 ` Steve Grubb 2015-01-08 13:33 ` Burak Gürer 2015-01-08 14:13 ` Steve Grubb 2015-01-12 10:12 ` auid=4294967295 issue Burak Gürer 2015-01-12 14:54 ` Steve Grubb 2015-01-08 16:39 ` Audit rotate David Flatley 2015-01-08 16:46 ` Steve Grubb 2015-01-08 17:17 ` David Flatley 2015-01-08 17:23 ` Steve Grubb 2015-01-08 17:47 ` David Flatley
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.