All,
I've been running in compliance with this rule for quite some time now and I'm noticing that the amount of noise that it produces is simply outrageous.
The suggestion is:
At a minimum the audit system should collect file permission changes for all users and root. Add the following to "/etc/audit/audit.rules":
-a always,exit -F arch=b32 -S chown -F auid>=500 -F auid!=4294967295 \ -k perm_mod
If the system is 64 bit then also add the following:
-a always,exit -F arch=b64 -S chown -F auid>=500 -F auid!=4294967295 \ -k perm_mod
And here is the output of a normal workstation over about a week of auditing and normal usage:
Syscall Summary Report ========================== total syscall ========================== 24907 chmod 15870 chown 11169 rename 7409 open 6462 fchmod 5290 fchown 3687 umount2 1443 setsid 1166 fsetxattr 869 removexattr 456 adjtimex 360 fchmodat 337 lchown 211 setuid 69 mkdir 63 setsockopt 33 unlink 22 setxattr 20 clone 19 execve 7 fchownat 7 mount 7 creat 4 close 4 ioctl 3 symlink 2 mknod 1 rmdir 1 lsetxattr 1 clock_settime 1 capset
So, I get why this can be useful. But I'm not so sure that it's useful to know that Pidgin dropped a new temp file every few minutes or that, each time I open a file (and write a temp file), that I did this as a normal user.
I just can't see the practicality of going through those top three calls on a regular basis.
I'm not necessarily suggesting that this type of thing be dropped but I'd like to understand how auditors won't fall into just ignoring them completely.
Thoughts?
Thanks,
Trevor
On Thursday, June 27, 2013 06:30:00 PM Trevor Vaughan wrote:
I've been running in compliance with this rule for quite some time now and I'm noticing that the amount of noise that it produces is simply outrageous.
The suggestion is:
At a minimum the audit system should collect file permission changes for all users and root. Add the following to "/etc/audit/audit.rules":
-a always,exit -F arch=b32 -S chown -F auid>=500 -F auid!=4294967295 \ -k perm_mod
If the system is 64 bit then also add the following:
-a always,exit -F arch=b64 -S chown -F auid>=500 -F auid!=4294967295 \ -k perm_mod
And these rules are incomplete. You also need -S fchmod -S fchmodat -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr
And here is the output of a normal workstation over about a week of auditing and normal usage:
This is not the output generated by the rule above. :-) To get that you would to run:
ausearch --start this-week -k perm_mod
What is more interesting than the syscall list you have below is the files and programs causing it
ausearch --start this-week -k perm_mod --raw | aureport -x --summary and ausearch --start this-week -k perm_mod --raw | aureport -f --summary
Personally, I don't think its terribly interesting to see permission changes in a user's home directory. You might want to know that permissions changed on the user's home dir, but its uninteresting for anything it contains.
I can certainly see this as interesting for system directories. Anyone recall what the threat was that this rule was watching for?
-Steve
Syscall Summary Report
total syscall
24907 chmod 15870 chown 11169 rename 7409 open 6462 fchmod 5290 fchown 3687 umount2 1443 setsid 1166 fsetxattr 869 removexattr 456 adjtimex 360 fchmodat 337 lchown 211 setuid 69 mkdir 63 setsockopt 33 unlink 22 setxattr 20 clone 19 execve 7 fchownat 7 mount 7 creat 4 close 4 ioctl 3 symlink 2 mknod 1 rmdir 1 lsetxattr 1 clock_settime 1 capset
So, I get why this can be useful. But I'm not so sure that it's useful to know that Pidgin dropped a new temp file every few minutes or that, each time I open a file (and write a temp file), that I did this as a normal user.
I just can't see the practicality of going through those top three calls on a regular basis.
I'm not necessarily suggesting that this type of thing be dropped but I'd like to understand how auditors won't fall into just ignoring them completely.
Thoughts?
Thanks,
Trevor
I think it was based on some set of (possibly now outmoded) DoD policy. And so the relationship to threat may not be clear. The DISA folks are most likely to know where it came from. Perhaps they could chime in.
Since it was originally written a while ago, prior to the transition to SRGs based on security controls in NIST 800-53, it's likely worth revisiting. If the OS SRG contains all the auditing rules necessary for a STIG, and there are no additional DoD requirements, then we should certainly be able to consider adjustment. This has the OS SRG reqs: http://www.stigviewer.com/stig/8ac5f3a06149beaa9ce61225390a6d60f88b2ac9/MAC1...
On Fri, Jun 28, 2013 at 10:36 AM, Steve Grubb sgrubb@redhat.com wrote:
On Thursday, June 27, 2013 06:30:00 PM Trevor Vaughan wrote:
I've been running in compliance with this rule for quite some time now
and
I'm noticing that the amount of noise that it produces is simply
outrageous.
The suggestion is:
At a minimum the audit system should collect file permission changes for all users and root. Add the following to "/etc/audit/audit.rules":
-a always,exit -F arch=b32 -S chown -F auid>=500 -F auid!=4294967295 \ -k perm_mod
If the system is 64 bit then also add the following:
-a always,exit -F arch=b64 -S chown -F auid>=500 -F auid!=4294967295 \ -k perm_mod
And these rules are incomplete. You also need -S fchmod -S fchmodat -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr
And here is the output of a normal workstation over about a week of auditing and normal usage:
This is not the output generated by the rule above. :-) To get that you would to run:
ausearch --start this-week -k perm_mod
What is more interesting than the syscall list you have below is the files and programs causing it
ausearch --start this-week -k perm_mod --raw | aureport -x --summary and ausearch --start this-week -k perm_mod --raw | aureport -f --summary
Personally, I don't think its terribly interesting to see permission changes in a user's home directory. You might want to know that permissions changed on the user's home dir, but its uninteresting for anything it contains.
I can certainly see this as interesting for system directories. Anyone recall what the threat was that this rule was watching for?
-Steve
Syscall Summary Report
total syscall
24907 chmod 15870 chown 11169 rename 7409 open 6462 fchmod 5290 fchown 3687 umount2 1443 setsid 1166 fsetxattr 869 removexattr 456 adjtimex 360 fchmodat 337 lchown 211 setuid 69 mkdir 63 setsockopt 33 unlink 22 setxattr 20 clone 19 execve 7 fchownat 7 mount 7 creat 4 close 4 ioctl 3 symlink 2 mknod 1 rmdir 1 lsetxattr 1 clock_settime 1 capset
So, I get why this can be useful. But I'm not so sure that it's useful to know that Pidgin dropped a new temp file every few minutes or that, each time I open a file (and write a temp file), that I did this as a normal user.
I just can't see the practicality of going through those top three calls
on
a regular basis.
I'm not necessarily suggesting that this type of thing be dropped but I'd like to understand how auditors won't fall into just ignoring them completely.
Thoughts?
Thanks,
Trevor
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Unfortunately, I completely understand the threat.
I believe the threat to be: If we know when all of these happen, then we'll be able to figure out who is trying to do what in case something bad happens.
I completely get it, but that's a heck of a lot of garbage data 99% of the time. I guess the real question is: Is the garbage data worth the 1%?
In response to Steve:
Wouldn't it be interesting to see a permission change in a user's home directory to 777 followed by some 644's or more 755's? This happens far too often to get around pesky noexec settings on /tmp ;-).
Thanks,
Trevor
On Mon, Jul 1, 2013 at 9:04 PM, Jeffrey Blank blank@eclipse.ncsc.milwrote:
I think it was based on some set of (possibly now outmoded) DoD policy. And so the relationship to threat may not be clear. The DISA folks are most likely to know where it came from. Perhaps they could chime in.
Since it was originally written a while ago, prior to the transition to SRGs based on security controls in NIST 800-53, it's likely worth revisiting. If the OS SRG contains all the auditing rules necessary for a STIG, and there are no additional DoD requirements, then we should certainly be able to consider adjustment. This has the OS SRG reqs:
http://www.stigviewer.com/stig/8ac5f3a06149beaa9ce61225390a6d60f88b2ac9/MAC1...
On Fri, Jun 28, 2013 at 10:36 AM, Steve Grubb sgrubb@redhat.com wrote:
On Thursday, June 27, 2013 06:30:00 PM Trevor Vaughan wrote:
I've been running in compliance with this rule for quite some time now
and
I'm noticing that the amount of noise that it produces is simply
outrageous.
The suggestion is:
At a minimum the audit system should collect file permission changes for all users and root. Add the following to "/etc/audit/audit.rules":
-a always,exit -F arch=b32 -S chown -F auid>=500 -F auid!=4294967295 \ -k perm_mod
If the system is 64 bit then also add the following:
-a always,exit -F arch=b64 -S chown -F auid>=500 -F auid!=4294967295 \ -k perm_mod
And these rules are incomplete. You also need -S fchmod -S fchmodat -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr
And here is the output of a normal workstation over about a week of auditing and normal usage:
This is not the output generated by the rule above. :-) To get that you would to run:
ausearch --start this-week -k perm_mod
What is more interesting than the syscall list you have below is the files and programs causing it
ausearch --start this-week -k perm_mod --raw | aureport -x --summary and ausearch --start this-week -k perm_mod --raw | aureport -f --summary
Personally, I don't think its terribly interesting to see permission changes in a user's home directory. You might want to know that permissions changed on the user's home dir, but its uninteresting for anything it contains.
I can certainly see this as interesting for system directories. Anyone recall what the threat was that this rule was watching for?
-Steve
Syscall Summary Report
total syscall
24907 chmod 15870 chown 11169 rename 7409 open 6462 fchmod 5290 fchown 3687 umount2 1443 setsid 1166 fsetxattr 869 removexattr 456 adjtimex 360 fchmodat 337 lchown 211 setuid 69 mkdir 63 setsockopt 33 unlink 22 setxattr 20 clone 19 execve 7 fchownat 7 mount 7 creat 4 close 4 ioctl 3 symlink 2 mknod 1 rmdir 1 lsetxattr 1 clock_settime 1 capset
So, I get why this can be useful. But I'm not so sure that it's useful
to
know that Pidgin dropped a new temp file every few minutes or that, each time I open a file (and write a temp file), that I did this as a normal user.
I just can't see the practicality of going through those top three
calls on
a regular basis.
I'm not necessarily suggesting that this type of thing be dropped but
I'd
like to understand how auditors won't fall into just ignoring them completely.
Thoughts?
Thanks,
Trevor
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On Wednesday, July 10, 2013 11:36:47 PM Trevor Vaughan wrote:
Unfortunately, I completely understand the threat.
I believe the threat to be: If we know when all of these happen, then we'll be able to figure out who is trying to do what in case something bad happens.
I completely get it, but that's a heck of a lot of garbage data 99% of the time. I guess the real question is: Is the garbage data worth the 1%?
Where are you seeing all these permission changes and what is doing it? You gave a syscall report as evidence which is not helpful to understand what the issue is and how we might resolve it.
In response to Steve:
Wouldn't it be interesting to see a permission change in a user's home directory to 777 followed by some 644's or more 755's? This happens far too often to get around pesky noexec settings on /tmp ;-).
If you wanted it, this will get it for you:
-a always,exit -S fchmodat -F dir=/home -F a2&0111 -F filetype=file -k mkexe -a always,exit -S fchmod,chmod -F dir=/home -F a1&0111 -F filetype=file -k mkexe
But this will catch only a naive user. The truly crafty users have to be caught another way. I'm still experimenting on how to do that.
-Steve
On Mon, Jul 1, 2013 at 9:04 PM, Jeffrey Blank blank@eclipse.ncsc.milwrote:
I think it was based on some set of (possibly now outmoded) DoD policy.
And so the relationship to threat may not be clear. The DISA folks are
most likely to know where it came from. Perhaps they could chime in.
Since it was originally written a while ago, prior to the transition to SRGs based on security controls in NIST 800-53, it's likely worth revisiting. If the OS SRG contains all the auditing rules necessary for a STIG, and there are no additional DoD requirements, then we should certainly be able to consider adjustment. This has the OS SRG reqs:
http://www.stigviewer.com/stig/8ac5f3a06149beaa9ce61225390a6d60f88b2ac9/MA C1PublicProfile/> On Fri, Jun 28, 2013 at 10:36 AM, Steve Grubb sgrubb@redhat.com wrote:
On Thursday, June 27, 2013 06:30:00 PM Trevor Vaughan wrote:
I've been running in compliance with this rule for quite some time now
and
I'm noticing that the amount of noise that it produces is simply
outrageous.
The suggestion is:
At a minimum the audit system should collect file permission changes for all users and root. Add the following to "/etc/audit/audit.rules":
-a always,exit -F arch=b32 -S chown -F auid>=500 -F auid!=4294967295 \ -k perm_mod
If the system is 64 bit then also add the following:
-a always,exit -F arch=b64 -S chown -F auid>=500 -F auid!=4294967295 \ -k perm_mod
And these rules are incomplete. You also need -S fchmod -S fchmodat -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr
And here is the output of a normal workstation over about a week of
auditing and normal usage:
This is not the output generated by the rule above. :-) To get that you would to run:
ausearch --start this-week -k perm_mod
What is more interesting than the syscall list you have below is the files and programs causing it
ausearch --start this-week -k perm_mod --raw | aureport -x --summary and ausearch --start this-week -k perm_mod --raw | aureport -f --summary
Personally, I don't think its terribly interesting to see permission changes in a user's home directory. You might want to know that permissions changed on the user's home dir, but its uninteresting for anything it contains.
I can certainly see this as interesting for system directories. Anyone recall what the threat was that this rule was watching for?
-Steve
Syscall Summary Report
total syscall
24907 chmod 15870 chown 11169 rename 7409 open 6462 fchmod 5290 fchown 3687 umount2 1443 setsid 1166 fsetxattr 869 removexattr 456 adjtimex 360 fchmodat 337 lchown 211 setuid 69 mkdir 63 setsockopt 33 unlink 22 setxattr 20 clone 19 execve 7 fchownat 7 mount 7 creat 4 close 4 ioctl 3 symlink 2 mknod 1 rmdir 1 lsetxattr 1 clock_settime 1 capset
So, I get why this can be useful. But I'm not so sure that it's useful
to
know that Pidgin dropped a new temp file every few minutes or that, each time I open a file (and write a temp file), that I did this as a normal user.
I just can't see the practicality of going through those top three
calls on
a regular basis.
I'm not necessarily suggesting that this type of thing be dropped but
I'd
like to understand how auditors won't fall into just ignoring them completely.
Thoughts?
Thanks,
Trevor
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
This is actually pretty funny:
On a workstation:
685 /usr/bin/pidgin 377 /usr/lib64/firefox/firefox 186 /usr/libexec/gconfd-2 94 /usr/lib64/vte/gnome-pty-helper 60 /usr/bin/vim 56 /usr/bin/pulseaudio 49 /usr/bin/mesg 36 /bin/sed 30 /bin/vi 10 /usr/libexec/gdm-session-worker 8 /usr/libexec/gnome-settings-daemon 5 /usr/lib64/libreoffice/program/soffice.bin 4 /usr/bin/less 4 /usr/bin/ruby 4 /usr/bin/gnome-volume-control-applet 3 /usr/bin/evince 2 /usr/bin/vinagre 2 /usr/bin/gnome-panel 1 /sbin/rsyslogd
So, it looks like my biggest culprits are...PIdgin and Firefox
On a server:
Executable Summary Report ================================= total file ================================= 63360 /usr/bin/ruby 202 /usr/bin/vim 55 /usr/sbin/sshd 36 /usr/bin/mesg 25 /bin/chmod 7 /usr/bin/python 5 /bin/chown 3 /usr/bin/less 2 /usr/sbin/httpd 2 /bin/vi 1 /usr/bin/man 1 /bin/chgrp
Tracking down the hits on Ruby was interesting.
It turns out that the auid > 500 works unless you run the command through a sudo session. Then, your auid is > 500 but your euid is < 500 for a given daemon service. Is this something that, from a guidance point of view, you would recommend ignoring due to the sheer mass of garbage data, or should it be collected since it's being run as a normal user?
Even so, 202 hits on VIM is a lot of garbage when you start aggregating systems.
Thanks,
Trevor
On Thu, Jul 11, 2013 at 10:54 AM, Steve Grubb sgrubb@redhat.com wrote:
On Wednesday, July 10, 2013 11:36:47 PM Trevor Vaughan wrote:
Unfortunately, I completely understand the threat.
I believe the threat to be: If we know when all of these happen, then
we'll
be able to figure out who is trying to do what in case something bad happens.
I completely get it, but that's a heck of a lot of garbage data 99% of
the
time. I guess the real question is: Is the garbage data worth the 1%?
Where are you seeing all these permission changes and what is doing it? You gave a syscall report as evidence which is not helpful to understand what the issue is and how we might resolve it.
In response to Steve:
Wouldn't it be interesting to see a permission change in a user's home directory to 777 followed by some 644's or more 755's? This happens far
too
often to get around pesky noexec settings on /tmp ;-).
If you wanted it, this will get it for you:
-a always,exit -S fchmodat -F dir=/home -F a2&0111 -F filetype=file -k mkexe -a always,exit -S fchmod,chmod -F dir=/home -F a1&0111 -F filetype=file -k mkexe
But this will catch only a naive user. The truly crafty users have to be caught another way. I'm still experimenting on how to do that.
-Steve
On Mon, Jul 1, 2013 at 9:04 PM, Jeffrey Blank <blank@eclipse.ncsc.mil wrote:
I think it was based on some set of (possibly now outmoded) DoD policy.
And so the relationship to threat may not be clear. The DISA folks
are
most likely to know where it came from. Perhaps they could chime in.
Since it was originally written a while ago, prior to the transition to SRGs based on security controls in NIST 800-53, it's likely worth revisiting. If the OS SRG contains all the auditing rules necessary
for a
STIG, and there are no additional DoD requirements, then we should certainly be able to consider adjustment. This has the OS SRG reqs:
http://www.stigviewer.com/stig/8ac5f3a06149beaa9ce61225390a6d60f88b2ac9/MA
C1PublicProfile/> On Fri, Jun 28, 2013 at 10:36 AM, Steve Grubb sgrubb@redhat.com
wrote:
On Thursday, June 27, 2013 06:30:00 PM Trevor Vaughan wrote:
I've been running in compliance with this rule for quite some time
now
and
I'm noticing that the amount of noise that it produces is simply
outrageous.
The suggestion is:
At a minimum the audit system should collect file permission changes for all users and root. Add the following to "/etc/audit/audit.rules":
-a always,exit -F arch=b32 -S chown -F auid>=500 -F
auid!=4294967295 \
-k perm_mod
If the system is 64 bit then also add the following:
-a always,exit -F arch=b64 -S chown -F auid>=500 -F
auid!=4294967295 \
-k perm_mod
And these rules are incomplete. You also need -S fchmod -S fchmodat -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr
And here is the output of a normal workstation over about a week of
auditing and normal usage:
This is not the output generated by the rule above. :-) To get that
you
would to run:
ausearch --start this-week -k perm_mod
What is more interesting than the syscall list you have below is the files and programs causing it
ausearch --start this-week -k perm_mod --raw | aureport -x --summary and ausearch --start this-week -k perm_mod --raw | aureport -f --summary
Personally, I don't think its terribly interesting to see permission changes in a user's home directory. You might want to know that permissions changed on the user's home dir, but its uninteresting for anything it contains.
I can certainly see this as interesting for system directories. Anyone recall what the threat was that this rule was watching for?
-Steve
Syscall Summary Report
total syscall
24907 chmod 15870 chown 11169 rename 7409 open 6462 fchmod 5290 fchown 3687 umount2 1443 setsid 1166 fsetxattr 869 removexattr 456 adjtimex 360 fchmodat 337 lchown 211 setuid 69 mkdir 63 setsockopt 33 unlink 22 setxattr 20 clone 19 execve 7 fchownat 7 mount 7 creat 4 close 4 ioctl 3 symlink 2 mknod 1 rmdir 1 lsetxattr 1 clock_settime 1 capset
So, I get why this can be useful. But I'm not so sure that it's
useful
to
know that Pidgin dropped a new temp file every few minutes or that, each time I open a file (and write a temp file), that I did this as a
normal
user.
I just can't see the practicality of going through those top three
calls on
a regular basis.
I'm not necessarily suggesting that this type of thing be dropped
but
I'd
like to understand how auditors won't fall into just ignoring them completely.
Thoughts?
Thanks,
Trevor
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide@lists.fedorahosted.org
-
Jeffrey Blank -
Steve Grubb -
Trevor Vaughan