I would consider this stepping into the realm of security through obscurity. If you consider the path being revealed to the local user a risk, I would recommend reconsidering as to whether or not the user having access to the system is a greater risk than the justification for them to have access.
It is also notable that Apache will often disclose riskier data than the file system paths as the result of application errors. If you insist on obfuscating the path in the logs, there is no native support for this in Apache. Nevertheless, you would be able to create this performance by piping Apache logs through a script or potentially sed using Piped Logs.
If you would like to further harden the local system against local users, there is a variety of more tangible methods that could prove to be helpful. The list below is focused on local hardening and is not comprehensive but should be a useful starting point.
- Removing the SUID bit from most files
- An audit of any files or directories that are writable to all.
- Removing code compilation tools.
- Removing absolutely all software including userland tools that are not integral to the system's role.
- Configuring packet filtering to limit external access to only that which is justified for the specific purpose of the systems role and operation.
- Enabling and configuring SELinux
- Apply and configure an Extended File Attribute policy
- Using Filesystem ACLs to further refine access to data on the local system
While there has not been a release since 2008, some of the policies applied within Bastille Linux also provide a general baseline for hardening Linux servers.
Many of these things will make the system more difficult to use and administer, which may frustrate users of a multiuser system that have shell access. Nevertheless, if security is the absolute priority, the methods listed will harden your system beyond that of the average multiuser system.