linux security - Mar 1998 - Re: Re: Re: Re: Towards a solution of tmp-file problems (fwd)

>Forwarding a message from Steve \"Stevers!\" Coile:
>> This is already possible.  Create the file then unlink it.  The file
>> contents aren''t deleted and i-node isn''t released
until the file is
>> closed.
>
>Without kernel support, unlinking the file at creation time requires
>a code change in the process which creates the file. And this
doesn''t
>protect scripts which use temp files for communication between their
>subprocesses, e.g.
>
>#!/bin/sh
>
>cat > /tmp/a.$$
>awk '' { print $1 } '' < /tmp.a.$$ | sort -o
/tmp/field1.$$
>awk '' { print $2 } '' < /tmp.a.$$ | sort -o
/tmp/field2.$$
>paste /tmp/field1.$$ /tmp/field2.$$
>rm -f /tmp/a.$$ /tmp/field1.$$ /tmp/field2.$$
>exit 0
>
>A private namespace protects this script and its subprocesses by making the
>files _totally_ inaccessible to unrelated processes. The private namespace
>can be imposed from above or the script can define its own.
How about creating a subdir in /tmp with 600 mode and
creating tmp files there ?

--
David Balazic , student
E-mail   : 1stein@writeme.com     |     living in  sLOVEnija
home page: http://surf.to/stein
Computer: Amiga 1200 + Quantum LPS-340AT
--

my 2c

All of these solutions have good & bad merit, but the bottom line is this, 
whilst a user is able to create symlinks into the /tmp directory most fail.

would it be possible to tell the kernel not to follow symlinks out of the /tmp 
directory as a broad based rule?

or have the kernel create a virtual filesystem that doesn''t allow 
symlinks/hardlinks?

IMHO, the only solution is going to be kernel based in this manner.

therefore if someone/thing creates a symlink, it would actually symlink to a 
chrooted filesystem that only exists within the kernel.  ie, if I do

ln -sf /etc/sendmail.cf /tmp/tmpfile.xxx

it would actually not link to .etc.sendmail.cf, but to a non existant file 
within the kernel (a chrooted virtual non useable filesystem)

just a thought.


Allen

Forwarding a message from DAVID BALAZIC:
> (nick@zeta.org.au writes)
> >A private namespace protects this script and its subprocesses by making
the
> >files _totally_ inaccessible to unrelated processes. The private
namespace
> >can be imposed from above or the script can define its own.
> 
> How about creating a subdir in /tmp with 600 mode and
> creating tmp files there ?
Like, say:

#!/bin/bash
mkdir /tmp/mydir
awk '' { print $1 } '' < infile > /tmp/mydir/file.$$

?

First you have to be sure that /tmp/mydir has not been replaced with a
symlink. You''d have to check the mode on /tmp, make sure it is 1777,
create the directory, make sure the directory you thought you created
is really there, and then you could do open within the directory.

There are more issues when setuid processes come into the picture. Do
you want a setuid process working in _your_ private directory?

[mod: I certainly would: I''d still be able to hack them... :-) -- REW]

Nick.
-- 
Zeta Internet                     SP4   Fax: +61-2-9233-6545 Voice: 9231-9400
G.P.O. Box 3400, Sydney NSW 1043        http://www.zeta.org.au/

DAVID BALAZIC writes:
> How about creating a subdir in /tmp with 600 mode and
> creating tmp files there ?
This is actually a good idea.  As you are able to verify mkdir fails
if it tries to create a directory over a symbolic link.  so a mkdir -m
700 is actually a hard thing to foil.

Incidentally, here at Transmeta, I''ve written a small utility called
''tmpdir'' that creates a directory exports its name to the
variable
$TMPDIR and then exec''s the command that you supply as an argument.

Example:

  tmpdir /var/tmp sh -c "cd \$TMPDIR; touch this; pwd; ls"

The intent of this binary ''wrapper'' is to make a temporary
workspace
available to an arbitrary program.  I guess it might be useful in a
security minded context too.

The program is a little more sophisticated than the above.  It
actually hangs around until the command has completed and then rm
-rf''s the $TMPDIR.

If there is any interest, I can see if Transmeta will permit me to
release the code.  [I could certainly see a case for doing this if the
commercial Linux distributions would volunteer to ship it as a
"standard" utility...]

Cheers

Andrew

On Thu, 12 Mar 1998, DAVID BALAZIC wrote:
> How about creating a subdir in /tmp with 600 mode and
> creating tmp files there ?
This will not prevent users themselves from trying to muck around with 
race conditions on their own tmp files... thus it''s only half a
solution...
not worth the hastle...

*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*-=-*
Wim Vandeputte                                       --Comfort is Treachery--
                                              --So pound the nails in tight--

Allen Bolderoff wrote...
> or have the kernel create a virtual filesystem that doesn''t allow 
> symlinks/hardlinks?
> IMHO, the only solution is going to be kernel based in this manner.
There might be reasons for wanting symlinks inside /tmp. An additional mount
option to not follow symlinks that cross devices can solve our problem here
(and might be useful for other things too)

Simply creating a 100mb-or-so partition for /tmp, and mount it with a
(to-be-kernel-supplied) "noxdevlink" option. Symlinks would be
perfectly
allowed on the /tmp directory (helps when untarring and compiling new software
in /tmp which uses symlinks), but no symlinks would be allowed to cross
filesystems. When /tmp is seperate, there would be no way to symlink /tmp to
important /etc files, or anything else.

Kernel would probably have to give EPERM (permission denied) on any attempt
to follow a symlink crossing devices, if the symlink started on a no-symlink
device. There would be no need for a new filesytem type, just a mount
option. This probably could be managed before 2.2 (probably, not too sure
of kernel internals)

-- 
Arnold Hendriks

I''m usually a lurker, but this gave me an idea. A filesystem firewall?
fsfw(4) and fsfwadm(8)...?

It could be a whole new fs but after a very quick glance, it looks like
some rearranging of fs/file_table.c would allow for a clean fs-independant
hook.

$.02,
.mario

On Fri, 13 Mar 1998, Allen Bolderoff wrote:
> (...)
> would it be possible to tell the kernel not to follow symlinks out of the
/tmp
> directory as a broad based rule?
> (...)
--
 Mario D. Santana Student Systems and Development San Francisco State
 President and CEO, El Orangutan, Ltd. Trying to make a better monkey
 Two Stupid Dogs Bert Ernie Johnny Bravo Dexter''s Lab Cow and Chicken
 mario@nin.net aka santana@linux_box.sfsu.edu aka pepito@undernet.irc