On 12/18/12 23:04, C. P. Ghost wrote:
On Tue, Dec 18, 2012 at 10:01 PM, Walter Hurry <walterhu...@gmail.com> wrote:
$ sudo /usr/libexec/locate.updatedb
WARNING
Executing updatedb as root. This WILL reveal all filenames
on your machine to all login users, which is a security risk.
$
Why is it a "security risk"? Security through obscurity? Really? In this
day and age?
Or am I missing something?
Suppose someone managed to start a shell under your account
and is seeking to escalate privileges, i.e. to become root. If he can
look at a full unrestricted locatedb, he may pay particular attention
to config files, log files etc... that may otherwise be hidden from sight.
locate.updatebd is _not_ run as root by default.
See Polytropon's and other replies.
If root runs it, it is root's responsibility that others can obtain all
filenames on the system.
Just by looking at this, he may infer that a particular software package
at a particular revision is actually running on that host and is configured
in a particular way. E.g., he may see that logfiles accumulate in /var/log
and are cleaned only once a week. It would be then easy to induce that
program to create more log files, thus denying service to other programs
that need /var as well. This, in turn, could result in real exploits of those
other programs...
Sure, most of this is already world-visible and in the regular locatedb
because we're so liberal with the rights of /var/db/pkg, /var/log, /etc, ... but
some admins prefer to hide particularly sensitive programs, their configs,
logs etc., in a non-world-readable directory hierarchy. Running
locate.updatedb(8) with root privileges would defeat that strategy.
That's why it is discouraged.
Of course, this is even more necessary when you have regular users on
that machine that don't necessarily trust each others. They wouldn't like
their home dirs to be world-readable by default by everyone else. Maybe
they won't object (and set /home/$USER to -rwxr-xr-x instead of -rwxr-x---
or -rwx------) but that's their call, not the sysadmin's.
-cpghost.
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
