C Looking for opinions on file-based auditing

[kandreww]

Hi all, I'm working on what will hopefully eventually be a port/package for doing audit logging based on files (as opposed to the current system which only allows user-based auditing), but am conflicted on how it should be designed. The passion project started from my employer's need for PCI-compliant file integrity monitoring (though my employer won't be using what I make so this is just a hobby project) and an apparent lack of file filtering in FreeBSD auditing, so my first thought was that it ought to be an easy(-ish) to use system with simple configuration; something like:
# file path : what to log : exclude?
/bin:write:
/home:all:exclude
/private:read:

But the more I write the program the more I get lost in trying to interpret what should count as what -- should running stat on a file be counted as a read? would literally anyone care if someone statted a file? And the more I wonder if it should be a clone of /etc/security/audit_user for files; that is, it would be like:
# user : audit classes to log : audit classes not to log
root:all:no
nfsuser:fw,fr:no

It seems like a classic dilemma of ease-of-use versus customization capabilities but I suppose the problem is I'm not expecting anyone to use this anyways and I have no target audience (that I think would realistically use my project), so I've no idea which direction I want to go. Hopefully y'all can make the decision for me

 

[ralphbsz]

You are confusing policy with mechanism. And you are doing the #1 failure of all software engineering: Not analyzing your requirements.

First step, requirements: What do YOU need? What do you expect to need in the near or medium term future? If this is for some regulatory thing (the acronym PCI makes me think it is), the answer for that might come from reading the regulation.

Second step: Design a mechanism that is suitably generic: generic enough to fulfill your current requirements, flexible enough that it will be able to grow in the future, but as simple (efficient to run, easy to write and maintain, reliable because of lack of moving parts) as possible. This is a very difficult tradeoff between extra engineering effort versus future value.

Third step: Build a prototype using the mechanism. See whether it works, and check that your assumptions weren't too wrong. Fully expect to throw your prototype away (see Fred Brooks: You will throw your first implementation away). On the other hand, if you build a joke prototype that doesn't do the task at hand, you won't learn anything from it. Difficult compromise. My suggestion: Build the first prototype in an easy-to-develop language (I would use python, tastes differ).

Zeroest step: Don't build, steal. Start by reading the handbook chapter on auditing. There is already a lot of infrastructure present for you; the easiest solution is likely to put a minimal layer on top of the existing code, at least for the first prototype.

And a few details to your questions:
"what to log : exclude?" How about using ownership user/group instead of directory? I bet in a financial server, all the relevant files will be used by a separate user (not root, not the user login of the administrator). Also, a quick look at the handbook shows that auditing can be enabled by user.

"should running stat on a file be counted as a read" Yes, probably. Because the length or change time of a file is important information for an intruder. And it is easy to add, and it will not use lots of bandwidth compared to the reads.

 

[kent_dorfman766]

<sarcasm>It's just software. I mean how hard can it be?</sarcasm>