I need a way with RedHat 7.3, 7.3, and 8.0 to track file access attemps to unauthorized files. For example, someone other than root tries to modify the shadow file. I would like to know who, and when the attempt was made.

TIA

Steve

Without enabling full process accounting you couldn't do this. Full process accounting is a bear to administer and eats up tons of disk space for logging.

You could try to create wrapper scripts around editing utilites such as vi but if the user is smart enough to know how to modify the files they are likely smart enough to avoid this.

Wrapper script example:

1) Determine location of vi by typing "which vi". On my servers this is an alias to "vim". If this is the case you then do a "which vim". This reveals it to be /usr/bin/vim.

2) Rename the original utility:
mv /usr/bin/vim /usr/bin/vim.real

3) Create a new script named with the original name of the utility:
/usr/bin/vim.real /usr/bin/vim (Note: Have to type in vim.real here because the vi alias doesn't work at this point since it can't find "/usr/bin/vim" until after you create this script.)

4) Insert the following lines in your vim session started in step 3:
#!/bin/bash
ARGS=$@
LOG=/var/log/vimlog
date >>$LOG # Record a date stamp in the file for this access.
who am i >>$LOG # Record REAL user ID and associated info
whoami >>$LOG # Record EFFECITVE user ID
echo "Arguments were $ARGS" >> $LOG # Record arguments including filename
/usr/bin/vim.real $ARGS # Do the vim session requested by user

5) Write and quit the vim session.

6) chmod 755 /usr/bin/vim

The problem with above is the user may someday figure out they're actually doing vim.real instead of vim. If they type in full path of vim.real they'll bypass your wrapper. Also if you install a new version of vim someday it would overwrite your wrapper and you'd have to remember to put in back in place.

You can use "samhain" for example. It will tell you when a file has been accessed.

I need a way with RedHat 7.3, 7.3, and 8.0 to track file access attemps to unauthorized files. For example, someone other than root tries to modify the shadow file. I would like to know who, and when the attempt was made.
IMSNHO the first question should always be "what are you trying to do?".
- If the shadow files have the proper rights then no other account user should be able to modify /etc/shadow,
- Auditing access to system files is no substitute for proper system hardening which should be a first priority.

If you want to log access attempts, then a wrapper like Jlightner suggested won't work in all situations (like he mentioned). What you need is a few things:
- A host that is hardened in general. Without that basis all other efforts are a waste of time. Please check out the LQ FAQ: Security references.
- A way to deny processes access to files and to log access. In Kernel 2.6.x you would have SELinux (or GRSecurity, but can't have both at the same time), 2.4.x can only use GRSecurity kernel patch.
- A way to allow "trusted" users to perform root account tasks. I'd opt for Sudo + Rootsh + noexec. Sudo allows you to authorise people to perform root account tasks, Rootsh logs the whole shell session and noexec will allow for instance a vi session to be opened, but without allowing access to subshells. (This clearly is not enough if you also want to protect the system against fsck ups: then you would need a wrapper that for instance copies out a conf file from CVS, let the user change it, and then diff and inspect the changes before committing. Though if you're at that point you probably shouldn't hand out sudo access anyway).


You can use "samhain" for example. It will tell you when a file has been accessed.
AFAIK Samhain will detect changes made to a file, just like Aide or even sha1sum would, but that is a passive check. If you want to deny access you will have to resort to blocking *before* the file is opened. This means you've gotta intercept the syscall.

Well. The bottom line is that we do have the system "locked down" but we have been mandated to have an audit trail of anyone trying to access these files/directories for which they do not have permissions.