Annotation of src/share/man/man7/setuid.7, Revision 1.2
1.2 ! martin 1: .\" $NetBSD: setuid.7,v 1.1 2003/02/17 10:30:34 wiz Exp $
1.1 wiz 2: .\"
3: .\" Copyright (c) 2003 The NetBSD Foundation, Inc.
4: .\" All rights reserved.
5: .\"
6: .\" This code is derived from software contributed to The NetBSD Foundation
7: .\" by Henry Spencer <henry@spsystems.net>.
8: .\"
9: .\" Redistribution and use in source and binary forms, with or without
10: .\" modification, are permitted provided that the following conditions
11: .\" are met:
12: .\" 1. Redistributions of source code must retain the above copyright
13: .\" notice, this list of conditions and the following disclaimer.
14: .\" 2. Redistributions in binary form must reproduce the above copyright
15: .\" notice, this list of conditions and the following disclaimer in the
16: .\" documentation and/or other materials provided with the distribution.
17: .\"
18: .\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
19: .\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
20: .\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
21: .\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
22: .\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
23: .\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
24: .\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
25: .\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
26: .\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
27: .\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
28: .\" POSSIBILITY OF SUCH DAMAGE.
29: .\"
30: .Dd February 10, 2003
31: .Os
32: .Dt SETUID 7
33: .Sh NAME
34: .Nm setuid
35: .Nd checklist for security of setuid programs
36: .Sh DESCRIPTION
37: .Em Please note :
38: This manual page was written long ago, and is in need of updating to
39: match today's systems.
40: We think it is valuable enough to include, even though parts of it
41: are outdated.
42: A carefully-researched updated version
43: would be very useful, if anyone is feeling enthusiastic...
44: .Pp
45: Writing a secure setuid (or setgid) program is tricky.
46: There are a number of possible ways of subverting such a program.
47: The most conspicuous security holes occur when a setuid program is
48: not sufficiently careful to avoid giving away access to resources
49: it legitimately has the use of.
50: Most of the other attacks are basically a matter of altering the program's
51: environment in unexpected ways and hoping it will fail in some
52: security-breaching manner.
53: There are generally three categories of environment manipulation:
54: supplying a legal but unexpected environment that may cause the
55: program to directly do something insecure,
56: arranging for error conditions that the program may not handle correctly,
57: and the specialized subcategory of giving the program inadequate
58: resources in hopes that it won't respond properly.
59: .Pp
60: The following are general considerations of security when writing
61: a setuid program.
62: .Bl -bullet
63: .It
64: The program should run with the weakest userid possible, preferably
65: one used only by itself.
66: A security hole in a setuid program running with a highly-privileged
67: userid can compromise an entire system.
68: Security-critical programs like
69: .Xr passwd 1
70: should always have private userids, to minimize possible damage
71: from penetrations elsewhere.
72: .It
73: The result of
74: .Xr getlogin 2
75: or
76: .Xr ttyname 3
77: may be wrong if the descriptors have been meddled with.
78: There is
79: .Em no
80: foolproof way to determine the controlling terminal
81: or the login name (as opposed to uid) on V7.
82: .It
83: On some systems, the setuid bit may not be honored if
84: the program is run by root,
85: so the program may find itself running as root.
86: .It
87: Programs that attempt to use
88: .Xr creat 3
89: for locking can foul up when run by root;
90: use of
91: .Xr link 2
92: is preferred when implementing locking.
93: Using
94: .Xr chmod 2
95: for locking is an obvious disaster.
96: .It
97: Breaking an existing lock is very dangerous; the breakdown of a locking
98: protocol may be symptomatic of far worse problems.
99: Doing so on the basis of the lock being
100: .Sq old
101: is sometimes necessary,
102: but programs can run for surprising lengths of time on heavily-loaded
103: systems.
104: .It
105: Care must be taken that user requests for I/O are checked for
106: permissions using the user's permissions, not the program's.
107: Use of
108: .Xr access 2
109: is recommended.
110: .It
111: Programs executed at user request (e.g. shell escapes) must
112: not receive the setuid program's permissions;
113: use of daughter processes and
114: .Dq setuid(getuid())
115: plus
116: .Dq setgid(getgid())
117: after
118: .Xr fork 2
119: but before
120: .Xr exec 3
121: is vital.
122: .It
123: Similarly, programs executed at user request must not receive other
124: sensitive resources, notably file descriptors.
125: .\" Use of
126: .\" .Xr closeall 3
127: .\" or close-on-exec arrangements,
128: .\" on systems which have them,
129: .\" is recommended.
130: .Pp
131: Programs activated by one user but handling traffic on behalf of
132: others (e.g. daemons) should avoid doing
133: .Dq setuid(getuid())
134: or
135: .Dq setgid(getgid()) ,
136: since the original invoker's identity is almost certainly inappropriate.
137: On systems which permit it, use of
138: .Dq setuid(geteuid())
139: and
140: .Dq setgid(getegid())
141: is recommended when performing work on behalf of the system as
142: opposed to a specific user.
143: .It
144: There are inherent permission problems when a setuid program executes
145: another setuid program,
146: since the permissions are not additive.
147: Care should be taken that created files are not owned by the wrong person.
148: Use of
149: .Dq setuid(geteuid())
150: and its gid counterpart can help, if the system allows them.
151: .It
152: Care should be taken that newly-created files do not have the wrong
153: permission or ownership even momentarily.
154: Permissions should be arranged by using
155: .Xr umask 2
156: in advance, rather than by creating the file wide-open and then using
157: .Xr chmod 2 .
158: Ownership can get sticky due to the limitations of the setuid concept,
159: although using a daughter process connected by a pipe can help.
160: .It
161: Setuid programs should be especially careful about error checking,
162: and the normal response to a strange situation should be termination,
163: rather than an attempt to carry on.
164: .El
165: .Pp
166: The following are ways in which the program may be induced to carelessly
167: give away its special privileges.
168: .Bl -bullet
169: .It
170: The directory the program is started in, or directories it may
171: plausibly
172: .Xr chdir 2
173: to, may contain programs with the same names as system programs,
174: placed there in hopes that the program will activate a shell with
175: a permissive
176: .Ev PATH
177: setting.
178: .Ev PATH
179: should
180: .Em always
181: be standardized before invoking a shell
182: (either directly or via
183: .Xr popen 3
184: or
185: .Xr execvp 3
186: or
187: .Xr execlp 3 ) .
188: .It
189: Similarly, a bizarre
190: .Ev IFS
191: setting may alter the interpretation of a shell command in really
192: strange ways, possibly causing a user-supplied program to be invoked.
193: .Ev IFS
194: too should always be standardized before invoking a shell.
195: .It
196: Environment variables in general cannot be trusted.
197: Their contents should never be taken for granted.
198: .It
199: Setuid shell files (on systems which implement such) simply cannot
200: cope adequately with some of these problems.
201: They also have some nasty problems like trying to run a
202: .Pa \&.profile
203: when run under a suitable name.
204: They are terminally insecure, and must be avoided.
205: .It
206: Relying on the contents of files placed in publically-writable
207: directories, such as
208: .Pa /tmp ,
209: is a nearly-incurable security problem.
210: Setuid programs should avoid using
211: .Pa /tmp
212: entirely, if humanly possible.
213: The sticky-directories modification (sticky bit on for a directory means
214: only owner of a file can remove it) helps,
215: but is not a complete solution.
216: .It
217: A related problem is that
218: spool directories, holding information that the program will trust
219: later, must never be publically writable even if the files in the
220: directory are protected.
221: Among other sinister manipulations that can be performed, note that
222: on many Unixes, a core dump of a setuid program is owned
223: by the program's owner and not by the user running it.
224: .El
225: .Pp
226: The following are unusual but possible error conditions that the
227: program should cope with properly (resource-exhaustion questions
228: are considered separately, see below).
229: .Bl -bullet
230: .It
231: The value of
232: .Ar argc
233: might be 0.
234: .It
235: The setting of the
236: .Xr umask 2
237: might not be sensible.
238: In any case, it should be standardized when creating files
239: not intended to be owned by the user.
240: .It
241: One or more of the standard descriptors might be closed, so that
242: an opened file might get (say) descriptor 1, causing chaos if the
243: program tries to do a
244: .Xr printf 3 .
245: .It
246: The current directory (or any of its parents)
247: may be unreadable and unsearchable.
248: On many systems
249: .Xr pwd 1
250: does not run setuid-root,
251: so it can fail under such conditions.
252: .It
253: Descriptors shared by other processes (i.e., any that are open
254: on startup) may be manipulated in strange ways by said processes.
255: .It
256: The standard descriptors may refer to a terminal which has a bizarre
257: mode setting, or which cannot be opened again,
258: or which gives end-of-file on any read attempt, or which cannot
259: be read or written successfully.
260: .It
261: The process may be hit by interrupt, quit, hangup, or broken-pipe signals,
262: singly or in fast succession.
263: The user may deliberately exploit the race conditions inherent
264: in catching signals;
265: ignoring signals is safe, but catching them is not.
266: .It
267: Although non-keyboard signals cannot be sent by ordinary users in V7,
268: they may perhaps be sent by the system authorities (e.g. to
269: indicate that the system is about to shut down),
270: so the possibility cannot be ignored.
271: .It
272: On some systems there may be an
273: .Xr alarm 3
274: signal pending on startup.
275: .It
276: The program may have children it did not create.
277: This is normal when the process is part of a pipeline.
278: .It
279: In some non-V7 systems, users can change the ownerships of their files.
280: Setuid programs should avoid trusting the owner identification of a file.
281: .It
282: User-supplied arguments and input data
283: .Em must
284: be checked meticulously.
285: Overly-long input stored in an array without proper bound checking
286: can easily breach security.
287: When software depends on a file being in a specific format, user-supplied
288: data should never be inserted into the file without being checked first.
289: Meticulous checking includes allowing for the possibility of non-ASCII
290: characters.
291: .It
292: Temporary files left in public directories like
293: .Pa /tmp
294: might vanish at inconvenient times.
295: .El
296: .Pp
297: The following are resource-exhaustion possibilities that the
298: program should respond properly to.
299: .Bl -bullet
300: .It
301: The user might have used up all of his allowed processes, so
302: any attempt to create a new one (via
303: .Xr fork 2
304: or
305: .Xr popen 3 )
306: will fail.
307: .It
308: There might be many files open, exhausting the supply of descriptors.
309: .\" Running
310: .\" .Xr closeall 3 ,
311: .\" on systems which have it,
312: .\" is recommended.
313: .It
314: There might be many arguments.
315: .It
316: The arguments and the environment together might occupy a great deal
317: of space.
318: .El
319: .Pp
320: Systems which impose other resource limitations can open setuid
321: programs to similar resource-exhaustion attacks.
322: .Pp
323: Setuid programs which execute ordinary programs without reducing
324: authority pass all the above problems on to such unprepared children.
325: Standardizing the execution environment is only a partial solution.
326: .\" .Sh SEE ALSO
327: .\" .Xr closeall 3
328: .Sh HISTORY
329: Written by Henry Spencer, and based on additional outside contributions.
330: .Sh AUTHORS
331: .An Henry Spencer Aq henry@spsystems.net
332: .Sh BUGS
333: The list really is rather long...
334: and probably incomplete.
CVSweb <webmaster@jp.NetBSD.org>
![[BACK]](/icons/back.gif){kind=icon}
Return to setuid.7 CVS log ![[TXT]](/icons/text.gif){kind=icon}
![[DIR]](/icons/dir.gif){kind=icon}
Up to [cvs.NetBSD.org] / src / share / man / man7