From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Why exclude unset auid in STIG rules Date: Wed, 11 May 2016 15:10:17 -0400 Message-ID: <4753435.QNXJuafnxx@x2> References: <6776565.2lPe2APqfW@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: "Wyatt, Curtis" Cc: "linux-audit@redhat.com" List-Id: linux-audit@redhat.com 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 different levels of paranoia. The STIG in my mind addresses basic robustness. If you read through the SRG, the things its requiring are reasonable but not paranoid. I also think of it as a starting point. You can certainly tighten your system more than the STIG calls out. This is because you have specific knowledge of your operating environment and the threats that go with it. This might be for example knowledge about a daemon you have installed and whether or not its likely to be compromised. You can, with specific knowledge, add rules just for that daemon. But I don't think everyone wants to be held to the needs of a particular setup. I think there is a difference in what rules you would use to spot bad user activity vs the rules you would use for intrusion detection. (I am working on and testing rules for intrusion detection and they will be in an upcoming release.) > In other words, if a daemon is compromised (or could be compromised), > wouldn't you want to monitor it's behavior as well? Perhaps if you feel that this is likely to happen in your environment. You may also wind up with so many events that you cannot see what a rogue employee just did right before they quit. Or so many events that you only can keep the last hour's logs on-hand. I don't see anything in the SRG that leans towards IDS-like rules. Do you see any? -Steve > -----Original Message----- > From: Steve Grubb [mailto:sgrubb@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 > 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 trigger > on user activity. It turns out that would trigger on daemons doing > something because 4294967295 is greater than 1000. So, we exclude daemons > because user activity is the prime target.