Derek's Unix Sysadmin tip of the day

[bogstad-e+AXbWqSrlAAvxtiuMwx3w at public.gmane.org (Bill Bogstad)]

On Sat, Oct 24, 2009 at 3:27 AM, Derek Martin <invalid-yPs96gJSFQo51KKgMmcfiw at public.gmane.org> wrote:
> I'm surrounded by smart people who know Unix/Linux very well, but from
> time to time I still hear that people think what I'm about to describe
> is impossible. ?I typed most of this up for a reason that became
> superfluous by the time I was done, so I figured I'd share it with you
> all, and at least *someone* is bound to find this useful. :)

Great post.  I've done something like this, but never saw the idea of
using membership of a group used as a gateway in quite this way before
now.  Some comments/suggestions:

1. You seem to have complicated your example somewhat by having an
'auditors' group.  No file or directory in your example is ever placed
in that group.  The important thing is that the auditors' accounts are
not in the accnting group and are in the finance group.

2. If people have multiple roles (in a single account) you can't
always assume that their primary group is the one in
which you want files to be created.  (The primary group is the one
which is normally used to set group ownership on new files.)
Fortunately, there is a mechanism to 'force' group ownership of new
files into a specified group.  If you do a 'chmod g+s directoryname'
on a directory all new files/directories created underneath that
directory will be created with the same group
as directoryname.  Even better, it seems like any new directories that
you create will have g+s automatically set as well.   So once you
start a directory tree this way, all descendant directories/files will
have the same properties. (I'm not sure if this is peculiar to
specific versions of Linux or not as I only recently learned about it
myself.)  In your example, I would have done a

sudo chmod g+s /tmp/finance/accounting

to make sure that all files created from that point down in the tree
were in the accounting group.

3. A variant of this can be done which allows an unprivileged user to
share access to a directory tree to multiple users
without recourse to groups.  Unfortunately, it doesn't really allow
me to do more then yes/no access unlike the groups method.

Here is a an example:

mkdir /tmp/secretstuff
chmod 711 /tmp/secretstuff
mkdir /tmp/secretstuff/FunKyPassword
chmod 755 /tmp/secretstuff/FunKyPassword

In this case the gateway mechanism, isn't based on membership in a
particular group, but rather on knowledge of the directory name
'FunKyPassword'.  Anyone who knows the pathname
/tmp/secretstuff/FunKyPassword can get there, but without that
knowledge you would have to do a brute force attack by trying all
possible strings in that position.  'FunKyPassword' can leak if you
aren't careful via command line arguments (i.e. ps).  Environment
variables set by 'cd' macros/functions might be an issue was well, but
it seems like on most systems only the owner (or root) can view them
with ps.  Shell history files are another possible 'leakage' point if
you aren't careful.  (Which is already a privacy concern
if they are world readable.)

GOOD usage:

cd /tmp/secretstuff/FunKyPassword
vi boring.txt

'cd' doesn't show up in 'ps' commands and /proc/###/cwd isn't
accessible to non-privileged users.

BAD usage:

vi /tmp/secretstuff/FunKyPassword/boring.txt

'ps' will show full pathname.

Individual accessors of this restricted directory can make it more
user friendly with something like the following:

mkdir $HOME/secrets
chmod 700 $HOME/secrets
ln -s /tmp/secretstuff/FunKyPassword $HOME/secrets/funky

Now I can do "cd $HOME/secrets/funky" instead of "cd
/tmp/secretstuff/FunKyPassword".

The chmod 700 on secrets means that the easy to remember aliases for
the more complicated passwords
are only usable by the owner of the $HOME/secrets directory (me).
Shell completion of directory names will
work for cd $HOME/secrets as well.  Multiple users can share access to
different directory trees with me and I can put
all of the symbolic links in $HOME/secrets without compromising the
independence of their security.

Yes, $HOME/secrets is the equivalent of writing down the password.  As
I see it, if my account/the system has been compromised to the point
that setting permissions to 700 isn't enough then they could trojan
horse my account anyway and grab the password/directory name that way.
 (Or easier yet just read it from my .bash_history file.)

Historically, I first saw the idea of having a directory name be a
password used with anonymous ftp upload sites.
If you knew the name of the world writable directory you could cd
there and upload files.   Since all access was via
ftp; leakage via ps, etc. wasn't relevant.  Local shell accounts were
assumed to be trusted.  I still think it is useful even
if you assume local attackers, but you do have to be more careful.

Bill Bogstad