On Thu, 06 Jan 2005 15:52:50 CST, "Browder, Tom" said: logrotate doesn't do a very good job of handling "roll to next file when this one is 40M in size", because the cron job is probably not running at the time that the log gets to 40M. The semantics of "rotate at 2AM if it's over 40M then" are quite different from "rotate at current clocktime 11:37AM if we hit 40M then...". Also, in a priv-separated environment, only the "security officer" role should be allowed to remove an audit file (while logrotate's "rotate" command will rm the oldest one if/when needed). So you probably need to use *two* logrotate instances with separate config files, one for your system logs running in the "admin" role, and another for the audit logs running in the "security officer" role. In an SELinux environment, you'd probably need a dummy front-end that runs logrotate, and have an exec_auto_trans() to put the front end into the correct security context....

I can probably help here Casey, as Tom's been using Snare for a while. (Tom - feel free to correct any mistaken assumptions though!) :) On Thu, 2005-01-06 at 14:30 -0800, Casey Schaufler wrote: Usually, from a on-system filtering perspective, the auditor is interested in real user ID only. The other ID's are very useful in follow-up analysis though. Unsuccessfully as in, "Tried to unlink /etc/passwd, but failed". User motivations / finger slippages are a bit hard to cover ;) Generally, an administrator will want to group a bunch of system calls together under the banner of "attempted changes to a file" or "attempted changes to file attributes" (or a combination thereof). This is likely to include renames, unlinks, and so on. This is where it gets nasty doesn't it. ;) Tom can correct me here, but I suspect that ideally: * symlinks and links should be resolved. (even if the file linked to no longer actually exists - the final path name should still be reported/filtered on). Ideally, access to an symlink will actually generate TWO events - one for the symlink (open - read), one for the final file (open - as per user requirement). * mount point/pfs resolution is a lower priority to security administrators (as generally, on most systems, the mounting of a file system is worth investigation in-of-itself), but still may be worth doing. * inodes are often transitory for the sorts of files many people are interested in auditing (eg: Applix used to remove the old file, and recreate the file, with a new inode, whenever you saved something! Erk.) Bingo. The tradeoff of (potentially significant!) CPU/resource usage for Auditing is a decision many organisations are prepared to accept - monitoring every file-open, or unlink on the system is resource intensive, but may be a critical requirement for many audit users. See the vfs audit thread mentioned in my last email. Snare works this way (bouncing every single file open through to the audit daemon for resolution, when a user has requested file open auditing). Not optimal, which is why filtering in-kernel may be more appropriate - but even so, users have reported single-figure-percentage reductions in performance when file auditing + regexp filtering is used. Or perhaps not tricky exactly - just potentially prohibitively expensive wit respect to resources, depending on the implementation. Regards, Leigh. -- Leigh Purdie, Director - InterSect Alliance Pty Ltd http://www.intersectalliance.com/

On Fri, 2005-01-07 at 11:20 +1100, Leigh Purdie wrote: That's a meaningful statement for symlinks but not for hard links. With hard links there is no one 'final path name'; they're all just different names for the same inode. If I hard-link /etc/passwd to /tmp/fish then both of those are _real_ names for it. It would be almost impossible to implement a system which is asked to log 'all access to /etc/*' and includes in that the access to /tmp/fish. -- dwmw2

Casey Schaufler wrote: directories - so recording such access may not be spectacularly interesting to the person reviewing the logs (however, it might be VERY interesting to a HIDS system that is watching the logs). But I guess similar consequences would result from a symlink to a symlink to a symlink [ .. ] .. to a file - so I see what you mean. But that raises the question I guess.. If a user attempts to access /path/to/protected/file.txt, and ACLs block them at /path/to, what should the event report? Failed access to /path/to/protected/file.txt (at which point, the auditor wants to know 'how did they get that far in the directory tree??), or Failed access to /path/to (at which point, the auditor has no idea of an attempted attack on a 'sensitive file')? My feeling is that the second option is most useful, but if we follow the above logic to conclusion, perhaps we would receive both events. Yes. I don't think we should second-guess the intent of the auditor. If they request /etc/passwd, monitor that only. If they request /etc/*passwd*, that's a different story. -- Leigh Purdie, Director - InterSect Alliance Pty Ltd http://www.intersectalliance.com/

Although this is what I'd LIKE solaris to provide me, unfortunately, it doesn't actually provide the requested path (except in an earlier 'exec' event associated with the command in question, but this is not spectacularly useful): comet SolarisBSM 1 header,144,2,execve(2),,Fri Jan 14 11:18:01 EST 2005, + 887 msec path,/usr/bin/cat attribute,100555,root,bin,26738688,296,0 exec_args,2,cat,/home/george/test.txt subject,-2,red,other,red,other,467,0,0 0 0.0.0.0 return,success,0 sequence,1523 snareseq,1524 comet SolarisBSM 1 header,84,2,open(2) - read,fe,Fri Jan 14 11:18:01 EST 2005, + 895 msec path,/home/george subject,-2,red,other,red,other,467,0,0 0 0.0.0.0 return,failure: No such file or directory,-1 sequence,1529 snareseq,1530 However, solaris will provide the 'requested path' if you can access the directory, but the file does not actually exist (eg:) comet SolarisBSM 1 header,89,2,open(2) - read,fe,Fri Jul 23 16:07:58 GMT 2004, + 547 msec path,/var/ld/ld.config subject,red,red,other,red,other,1370,1339,2849 5888 10.0.0.1 return,failure: No such file or directory,-1 sequence,13 *laugh* What an amazingly graceful way of implying that CAPP and real- world user requirements are not always perfectly aligned. Very true. ;) See above comment ;) I don't personally have a problem with a subject/object approach, but I think that a level of wildcard audit filtering is a critical precondition for a successful (and effective!) audit implementation. This could conceivably be done is through object inheritance on directories (like Windows - c:\path\to\secretstuff\*), or through path- name filtering in the kernel. However, the windows approach can limit the flexibility of the auditor somewhat. I've mentioned examples before, but a good real-world one is the 'No foreign nationals' category of intelligence material (lets call the directory 'NOFRN'), but it could apply equally to budget/financial data, human resources information, or any other info that is sensitive, but distributed (and controlled by) many departments within an organisation. With a wildcard-based rule system, a security auditor can put a rule in place like match=.*/NOFRN/.*, and tell departments that auditing is available for their NOFRN data - all they need to do is place it in a 'NOFRN' subdirectory with their directory structure. With a object-inheritance structure, you'd either have to explicitly establish a rule for each new NOFRN directory, or modify your directory structure (and perhaps user practises somewhat) to accommodate auditing (which may not be a bad things in many circumstances). Neither approach is bad - but since we're still at the decision-making point from a filtering perspective, I thought I'd highlight some potential repercussions. :) Regards, Leigh. -- Leigh Purdie, Director - InterSect Alliance Pty Ltd http://www.intersectalliance.com/

Fair enough - I don't think anyone would begrudge us not performing miracles. ;) We'll just have to note it as a limitation in the doco, and let the end-user decide what they want to do. For some, they'll accept the risk that the file won't be audited (most will be in this category). Others may decide to turn on 'hard link auditing' for normal user accounts to get an indication that this might be happening. The more paranoid, may decide to audit all links, and file accesses, and post-process the log data to track down all file-opens to particular files (once resolved in the post-processing.. erm.. process. :) Regards, Leigh. -- Leigh Purdie, Director - InterSect Alliance Pty Ltd http://www.intersectalliance.com/

On Thursday 06 January 2005 16:52, Browder, Tom wrote: Yes. Its all rolled into that. The rule loader can probably do the translation of user to uid. Otherwise, I think the current framework does all this. That might save some diskspace. I'll add this near the bottom. No. Logrotate must stop and start daemons of they have a open descriptor. We need to do this ourselves. I'm pretty sure this can be done: assuming user x is uid 501 auditctl -a entry always -S unlink -F uid=501 arg0=file The main issue I see is figuring out what unsuccessful means and putting that into syntax. < is not an option. It might be success!=0. -Steve Grubb

This issue takes us back to the discussions around VFS auditing (https://www.redhat.com/archives/linux-audit/2004- December/msg00002.html) - in which was highlighted the need to audit files that either: * Do not currently exist / have an inode - eg: "Tell me whenever someone attempts to view a file called /etc/hosts.equiv, despite the fact that the file does not exist at the moment." * Match file/directory creation against a particular wildcard, regardless of whether they currently exist or not - eg: "Tell me whenever a file is created in a directory with the word 'SECRET' as part of the directory name, or - "Tell me whenever someone creates a file called '.rhosts' somewhere under the top directory '/home/*/'. Tagging an inode with an audit flag is a good starting point to gain a capability, but I think we need to find a more comprehensive solution to provide an effective auditing subsystem that meets the 'filtering' requirements of many organisations.. even if it's something like: * If inode exists for file, get real path, and filter on that basis. * else, realpath() the vfs_root, plus the argument supplied by the user in open() (note: there's a potential for race conditions here though). .. So 'cat /home/../etc/cron.daily/../hosts.equiv' : no such file or directory is reported as a failed access to /etc/hosts.equiv. Also, w.r.t the success flag, we've encountered situations where a user wants to filter on both: * A broad success/failure, and * specific return/error codes Most auditors just want to know whether the system call worked, or not (ie: did they run the command, or didn't they.. did they open the file, or not). Others, however, are particularly interested in particular return/error codes, and want to filter on that basis (eg: ignore logs relating to ENOEXEC's in execve attempts). I'm not suggesting adding in such filtering requirements specifically for particular system calls.. but providing both a 'indicative success value', and a 'specific return code' in each audit event is probably a good move. That way, an auditor doesn't have to 'man 2 open' or 'man every time they need to work out whether '-1', '0', or 'a non-zero positive value' actually indicates a 'success' for a particular system call. A good example of this might be execve. You should probably return both: * TRUE or FALSE (whether the command failed), and * The resulting return (for success) or error (for failure) code - eg: EACCES, EPERM, or ENOEXEC. This addition will certainly make filtering easier, and reduce the eventual volume of audit log information that needs to be reviewed by the security administrator. Regards, Leigh. On Thu, 2005-01-06 at 18:19 -0500, Steve Grubb wrote: -- Leigh Purdie, Director - InterSect Alliance Pty Ltd http://www.intersectalliance.com/