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(a)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(a)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(a)lists.fedorahosted.org
>>
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>
> _______________________________________________
> scap-security-guide mailing list
> scap-security-guide(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide