[balug-talk] updatedb: can not change group of file

[David Alban]

My program myupdatedb, run as "alban", creates a locate database of my
$HOME tree on a machine on which I'm not a privileged user.  This is
so that I can use my own "mylocate" to query that database.  With
myupdatedb I can update the database on my own schedule, and I can
make the use of regular expressions the default with mylocate.  The
database resides in my $HOME tree.  It ends up being owned by me,
group owned by  me, and perms 0600.  Here's myupdatedb:

  #!/bin/bash

  # $Id: myupdatedb,v 1.3 2006/09/28 04:13:03 alban Exp $

  umask 77

  PATH=/bin:/usr/bin; export PATH

  exclude="$HOME/foo $HOME/bar"

  db=$HOME/.../somedatabasefilename

  mygrp=$( grep ^$LOGNAME: /etc/passwd | cut -f4 -d: )

  updatedb --database-root $HOME       \
           --add-prunepaths "$exclude" \
           --require-visibility 0      \
           --output $db

Given that the database created/updated is created/updated with perms
0600, and my $HOME perms are 0700, I'm not really worried.  Besides,
if a hacker gets root on the system, I've got more to worry about then
bad people discovering the paths in my $HOME tree. :-)

FYI, my "mylocate" program looks like:

  #!/bin/bash

  # $Id: mylocate,v 1.3 2006/09/28 04:17:28 alban Exp $

  PATH=/bin:/usr/bin
  export PATH

  while [[ $2 ]]; do
    locate_args="$locate_args $1"
    shift
  done

  regexp="$1"
  [[ -z $1 ]] && exit 0

  db=$HOME/.../somedatabasefilename
  locate --database $db --regexp "$regexp" $locate_args

On 9/28/06, Michael Paoli <Michael.Paoli at cal.berkeley.edu> wrote:
> Well, I don't have version of updatedb at my fingertips that supports
> the
> -l, --require-visibility IFLAG
> option, but based on the description, I would guestimate that not
> using the default value of 1 could be a security issue.  E.g., I
> would presume with that option set to 0, something like the following
> would be the case:
> If a user does something like:
> $ (umask 066 &&
> > mkdir /var/tmp/mysecret &&
> > umask 0 &&
> > >/var/tmp/mysecret/cv60aXU8Gges82rY)
> other users (other than superuser), although they would have access
> to the file /var/tmp/mysecret/cv60aXU8Gges82rY, they wouldn't be able
> to discover the name of the file (unless they caught it in some ps(1)
> listing or discovered it via brute force or something like that), so
> the file would be effectively protected to a fair degree by a certain
> amount of security by obscrurity (this protection could be expanded
> by increasing the complexity/randomness and length of the filename
> and/or similarly layering it multiple levels deep under randomly
> named directories).  It would seem, however, that if updatedb is run
> by that user (or superuser) and scans /var/tmp/mysecret and the
> mentioned option is set to 0, that other users would then be able to
> use locate (or slocate or what have you) to determine the name of the
> file /var/tmp/mysecret/cv60aXU8Gges82rY, and similarly for other
> items (e.g. directories) beneath /var/tmp/mysecret where similar
> protection means may also be used/attempted.  Having updatedb
> effectively "leak" such security information would generally be
> considered a bad thing, and that's probably why the default is for
> that option to behave as if it is set to 1.
>
> Now, ... as to the chown32() failing (EPERM), if updatedb is SGID to
> slocate (or whatever group has GID 21), as would seem to be the case
> on at least some of the man pages I check (e.g.:
> http://www.google.com/search?hl=en&lr=&q=updatedb+%22--require-visibility%22+sgid&btnG=Search
> ), it seems a bit odd that the chown32() would fail - e.g. if it's
> SGID to GID 21, and you own the file it's attempting the chown32()
> on, and it's only trying to change the GID of the file to GID 21,
> then that should generally succeed.  Perhaps something a bit more
> interesting is going on?  What are the permissions on the updatedb
> program, is it a binary executable, and what are the permissions of
> all of the directories above the pathname upon which the chown32() is
> failing, and what group or groups have GID 21?  Do any setgid(2) or
> similar (setegid(2), seteuid(2), setfsuid(2), setregid(2),
> setreuid(2), setuid(2), etc.) calls show up in the strace?  Oh, and
> to make matters a bit more interesting, strace, invoked by
> non-superuser generally can't trace suid/sgid stuff.  E.g. when I
> attempt it, it appears the effect is that the suid/sgid on the binary
> traced effectively don't take effect.  Is the updatedb file on a
> filesystem that's mounted nosuid?  (and, "of course", I almost forgot
> this little detail, as I started a simple sgid test under my HOME
> directory ... but I've got /home mounted nosuid for security reasons;
> except for / and /usr (and /opt where applicable, and possibly some
> filesystems mounted beneath /usr and /opt), where the nosuid option
> is applicable, I generally prefer to mount filesystems nosuid ... I
> also like to generally have /usr (and some other filesystems) mounted
> ro most of the time, for both security and performance reasons - note
> also that having, e.g. /usr mounted ro on at least certain versions
> of Red Hat (and possibly also Fedora?) can be a bit problematic due
> to some nasty bugs in Red Hat - e.g. if /usr is mounted ro and one
> installs a package with rpm, the package database is updated, no
> errors are returned, but if any of the files were to be installed on
> /usr ... they don't get installed!!!  Debian is much smarter and more
> reasonable about things, and will at least return an error and not
> install the package if one does something like that with dpkg, and
> apt is smart enough that it can automagically remount /usr rw for
> installations/updates, and remount it ro (if it can) when completed -
> at least with suitable apt configuration).
>
> references/excerpts:
> http://lists.balug.org/pipermail/balug-talk-balug.org/2006-September/0
> 03817.html
> http://lists.balug.org/pipermail/balug-talk-balug.org/2006-September/0
> 03817.html

-- 
Live in a world of your own, but always welcome visitors.