Bugtraq mailing list archives

Re: Secure Locate v1.0


From: klindsay () PEACE NETNATION COM (Kevin Lindsay)
Date: Fri, 9 Oct 1998 13:37:51 -0700


I just released v1.1 (ftp.mkintraweb.com/pub/linux/slocate) It is now a
bit faster due to some suggestrions by Marc SCHAEFER
<schaefer () alphanet ch>.

How slocate works is this:

1) First a slocate group should be setup and assigned to the slocate
   binary:

   -r-xr-sr-x   1 root  slocate  43527 Oct  9 13:20   /usr/local/bin/slocate*

   Such as above. set gid to it as well.

2) The database file will automatically be created as:

   -rw-r-----   1 root   slocate  3285 Oct  9 13:12   /var/lib/slocate/slocate.db

   So that when slocate runs it can be read by the slocate binary but
   still be non readable by world. This way you cannot copy or view the
   database. Also having the binary setgid is not a security issue
   except if someone cracks the group id inwhich you probably have a
   problem else where.

3) With v1.1 now, the file perms are not stored in the database but
   instead are checked when a match has been found. That way the
   permissions are checked live. Its faster this way and the db is
   smaller. (should be the same size as the original locate db).

This way anyone on the system can use the same db and search through all
the files on the system that only they have access too.

But if the instructions are not read then it won't be setup properly. And
if it is not setup properly slocate won't run so no harm done anyways. (c:

-----------------------------
 NetNation Communications Inc
 Kevin Lindsay
 Technical Support

On Fri, 9 Oct 1998, David Bushong wrote:

Just out of curiousity, what's the advantage of storing the ownership
and permission?  Isn't that the whole point of running mklocatedb as
user "nobody"?  In fact, your version could be nice, because then users
would be able to do a locate on their own nazied files (because _they_
have permission to read them), but since it must run as root to index
everyone's files, it stores all the files on the system in the locate
database.  If it's world readable, thats way less secure than it was before,
and if it's not, that means your locate binary has to be setuid something,
making it less secure than before..  Am I missing something here?

--David Bushong

I have created a secure version of GNU's locate.  When it indexes the
files, it keeps a record of its permissions and ownership so that users
using slocate won't see files they don't have access to. It uses
incremental encoding the same as GNU's locate, but is is a bit slower
since the db gets quite large with the extra data.

It doesn't coredump on files over 127 bytes either. (c:

I wrote it on linux, but it compiles on FreeBSD as well. I don't have
any other platforms at the moment to test it on so any patches are
welcome.

Its my first release so there are probably a few bugs that I missed and
features to be changed/added.

You can send any bugs/requests to: klindsay () mkintraweb com

You can get a copy at:

ftp.mkintraweb.com/pub/linux/slocate/

Cheers!

_____________________________________________________________________
  _   _ _   _
 | \ | | \ | | Kevin Lindsay                  | Powered By Linux!
 |  \| |  \| | NetNation Communications Inc.  | Web Hosting Services
 | |\  | |\  | http://www.netnation.com/      | Linux Development
 |_| \_|_| \_| klindsay () mkintraweb com        | System Administration





Current thread: