1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
|
<!--startcut ==========================================================-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<title>Cleaning up your /tmp -- Revisited Issue 20</title>
</HEAD>
<BODY BGCOLOR="#EEE1CC" TEXT="#000000" LINK="#0000FF" VLINK="#0020F0"
ALINK="#FF0000">
<!--endcut ============================================================-->
<H4>
"Linux Gazette...<I>making Linux just a little more fun!</I>"
</H4>
<P> <HR> <P>
<!--===================================================================-->
<center>
<H2>Cleaning up you /tmp -- Revisited</H2>
<H4>By Guy Geens,
<a href="mailto:ggeens@iname.com">ggeens@iname.com</a></H4>
</center>
<P><HR>
<p><I>In issue 18, I described how to avoid certain security risks when
removing files from your <tt>/tmp</tt> directory.
I have received some letters as feedback, and I'll summarize the
issues here.
Some people said they didn't need the extra security. Well, they're
free <em>not</em> to use my script.</I>
<h2>mtime vs. atime</h2>
<p>Michael Veksler <tt><mveksler@VNET.IBM.COM></tt> told me he
was worried about the use of the access time to determine the file's
age. His main concern was that files could be ``accidently'' touched
by
<pre>
find ... | xargs grep ...
</pre>
constructions. Personally, I don't have this problem, as I tend to
restrict the domain of my <tt>find</tt> sweeps.
<p>As I said in my first article, it's a personal taste. I frequently
unpack archives in my <tt>/tmp</tt> hierarchy. And I want to be
certain the files will stay there until I don't need them anymore.
<p>To me, 3 days after last looking at the file seems a reasonable
delay for that.
<p>But recently, I started using <tt>afio</tt> for transporting files
that won't fit on one floppy. And <tt>afio</tt> Remembers the access
time during archiving, and also sets this date while unpacking. This
could limit the lifespan of my files if I don't look at them
immediately. (As a sidenote, <tt>zip</tt> also sets the access time.)
<p>Obviously, there is one other possibility I neglected: using ctime
(inode change time). It is not possible to set this to an arbitrary
value, and it doesn't change as easily as the access time.
<h2>Avoiding perl</h2>
<p>Perl has a rather large memory footprint, and is not available on
every site. Therefore, Francois Wautier <
suggested:
<pre>
cp -p /bin/rm-static /usr/bin/find-static /tmp
chroot /tmp /find-static ... -exec /rm-static {} \;
rm /tmp/rm-static /tmp/find-static
</pre>
<p><tt>rm-static</tt> and <tt>find-static</tt> are statically compiled
versions of <tt>rm</tt> and <tt>find</tt>, respectively. The
<tt>-p</tt> flag ensures the resulting binary is owned by
<tt>root</tt>, closing one security risk. (A user might have created
her own <tt>/tmp/rm-static</tt> with the intend of changing the binary.)
<p>This gives rise to a new set of race conditions, although they
aren't as easy to exploit as the
<pre>
find ... | xargs rm
</pre>
security hole described in my first article.
<p>In general, I would advise against executing arbitrary files with
<tt>root</tt> permissions, especially if they are residing in a
publicly writeable directory (like <tt>/tmp</tt>). (It is also related
to the reason why `<tt>.</tt>' should never be in <tt>root</tt>'s path.
<p>This leads me to a real security risk:
<h2>Perl's internals</h2>
<p>(This one I found myself.)
<p>I recently upgraded to perl 5.004. After the upgrade, I noticed my
<tt>cleantmp</tt> script started emitting warnings about not finding
the <tt>pwd</tt> program.
<p>I looked into the perl module code, and it uses <tt>pwd</tt> to
determine the current directory.
<p>The script itself doesn't have problems with the missing binary, as
I'm using absolute paths everywhere. But it opens a <b>huge</b>
security hole: An executable called <tt>pwd</tt> in the right place in
the <tt>/tmp</tt> tree can give a user a process executing with
<tt>root</tt> permissions.
<p>In this case, the <tt>chroot</tt> <em>decreases</em> security,
instead of increasing it.
<p>For this reason, I have decided to remove the <tt>chroot</tt> from
the script entirely. That way, I can be sure only trusted binaries are
executed.
<h2>Omitting certain files and directories</h2>
<p>In the first version of my script, I demonstrated how to exclude
some files from being deleted. I obviously forgot one thing: a user
could create files or directories with the same names, and they would
never be deleted.
<p>The solution is easy: test the owner of the file, and if it isn't
<tt>root</tt>, just delete the file.
<h2>cleantmp, version 2</h2>
<p>Here is a <a href="cleantmp2.0">link</a> to the new script.
Comments are welcome.
<hr>
<address>
<a href="mailto:ggeens@iname.com">Guy Geens</a>
</address>
<!--===================================================================-->
<P> <hr> <P>
<center><H5>Copyright © 1997, Guy Geens<BR>
Published in Issue 20 of the Linux Gazette, August 1997</H5></center>
<!--===================================================================-->
<P> <hr> <P>
<A HREF="./lg_toc20.html"><IMG ALIGN=BOTTOM SRC="../gx/indexnew.gif"
ALT="[ TABLE OF CONTENTS ]"></A>
<A HREF="../lg_frontpage.html"><IMG ALIGN=BOTTOM SRC="../gx/homenew.gif"
ALT="[ FRONT PAGE ]"></A>
<A HREF="./lg_answer20.html"><IMG SRC="../gx/back2.gif"
ALT=" Back "></A>
<A HREF="./breakin.html"><IMG SRC="../gx/fwd.gif" ALT=" Next "></A>
<P> <hr> <P>
<!--startcut ==========================================================-->
</BODY>
</HTML>
<!--endcut ============================================================-->
|
