Annotation of src/share/man/man7/setuid.7, Revision 1.5
1.5 ! joerg 1: .\" $NetBSD: setuid.7,v 1.4 2009/02/26 19:05:58 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: .\"
1.3 christos 30: .Dd February 26, 2009
1.5 ! joerg 31: .Dt SETUID 7
1.1 wiz 32: .Os
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.
1.3 christos 125: Use of
126: .Xr fcntl 2
127: .Dv F_CLOSEM ,
128: .Dv FILENO_STDERR + 1
129: (close all fd's greater than stderr)
130: and/or
131: .Xr fcntl 2
132: .Dv F_SETFD ,
133: .Dv FD_CLOEXEC
134: (close-on-exec) arrangements
135: on systems which have them
136: is recommended.
137: .Pp
138: Other resources should also be examined for sanity and possibly set to
139: desired settings, such as the current working directory, signal disposition,
140: resource limits, environment, umask, group membership, chroot.
1.1 wiz 141: .Pp
142: Programs activated by one user but handling traffic on behalf of
143: others (e.g. daemons) should avoid doing
144: .Dq setuid(getuid())
145: or
146: .Dq setgid(getgid()) ,
147: since the original invoker's identity is almost certainly inappropriate.
148: On systems which permit it, use of
149: .Dq setuid(geteuid())
150: and
151: .Dq setgid(getegid())
152: is recommended when performing work on behalf of the system as
153: opposed to a specific user.
154: .It
155: There are inherent permission problems when a setuid program executes
156: another setuid program,
157: since the permissions are not additive.
158: Care should be taken that created files are not owned by the wrong person.
159: Use of
160: .Dq setuid(geteuid())
161: and its gid counterpart can help, if the system allows them.
162: .It
163: Care should be taken that newly-created files do not have the wrong
164: permission or ownership even momentarily.
165: Permissions should be arranged by using
166: .Xr umask 2
167: in advance, rather than by creating the file wide-open and then using
168: .Xr chmod 2 .
169: Ownership can get sticky due to the limitations of the setuid concept,
170: although using a daughter process connected by a pipe can help.
171: .It
172: Setuid programs should be especially careful about error checking,
173: and the normal response to a strange situation should be termination,
174: rather than an attempt to carry on.
175: .El
176: .Pp
177: The following are ways in which the program may be induced to carelessly
178: give away its special privileges.
179: .Bl -bullet
180: .It
181: The directory the program is started in, or directories it may
182: plausibly
183: .Xr chdir 2
184: to, may contain programs with the same names as system programs,
185: placed there in hopes that the program will activate a shell with
186: a permissive
187: .Ev PATH
188: setting.
189: .Ev PATH
190: should
191: .Em always
192: be standardized before invoking a shell
193: (either directly or via
194: .Xr popen 3
195: or
196: .Xr execvp 3
197: or
198: .Xr execlp 3 ) .
199: .It
200: Similarly, a bizarre
201: .Ev IFS
202: setting may alter the interpretation of a shell command in really
203: strange ways, possibly causing a user-supplied program to be invoked.
204: .Ev IFS
205: too should always be standardized before invoking a shell.
206: .It
207: Environment variables in general cannot be trusted.
208: Their contents should never be taken for granted.
209: .It
210: Setuid shell files (on systems which implement such) simply cannot
211: cope adequately with some of these problems.
212: They also have some nasty problems like trying to run a
213: .Pa \&.profile
214: when run under a suitable name.
215: They are terminally insecure, and must be avoided.
216: .It
217: Relying on the contents of files placed in publically-writable
218: directories, such as
219: .Pa /tmp ,
220: is a nearly-incurable security problem.
221: Setuid programs should avoid using
222: .Pa /tmp
223: entirely, if humanly possible.
224: The sticky-directories modification (sticky bit on for a directory means
225: only owner of a file can remove it) helps,
226: but is not a complete solution.
227: .It
228: A related problem is that
229: spool directories, holding information that the program will trust
230: later, must never be publically writable even if the files in the
231: directory are protected.
232: Among other sinister manipulations that can be performed, note that
233: on many Unixes, a core dump of a setuid program is owned
234: by the program's owner and not by the user running it.
235: .El
236: .Pp
237: The following are unusual but possible error conditions that the
238: program should cope with properly (resource-exhaustion questions
239: are considered separately, see below).
240: .Bl -bullet
241: .It
242: The value of
243: .Ar argc
244: might be 0.
245: .It
246: The setting of the
247: .Xr umask 2
248: might not be sensible.
249: In any case, it should be standardized when creating files
250: not intended to be owned by the user.
251: .It
252: One or more of the standard descriptors might be closed, so that
253: an opened file might get (say) descriptor 1, causing chaos if the
254: program tries to do a
255: .Xr printf 3 .
256: .It
257: The current directory (or any of its parents)
258: may be unreadable and unsearchable.
259: On many systems
260: .Xr pwd 1
261: does not run setuid-root,
262: so it can fail under such conditions.
263: .It
264: Descriptors shared by other processes (i.e., any that are open
265: on startup) may be manipulated in strange ways by said processes.
266: .It
267: The standard descriptors may refer to a terminal which has a bizarre
268: mode setting, or which cannot be opened again,
269: or which gives end-of-file on any read attempt, or which cannot
270: be read or written successfully.
271: .It
272: The process may be hit by interrupt, quit, hangup, or broken-pipe signals,
273: singly or in fast succession.
274: The user may deliberately exploit the race conditions inherent
275: in catching signals;
276: ignoring signals is safe, but catching them is not.
277: .It
278: Although non-keyboard signals cannot be sent by ordinary users in V7,
279: they may perhaps be sent by the system authorities (e.g. to
280: indicate that the system is about to shut down),
281: so the possibility cannot be ignored.
282: .It
283: On some systems there may be an
284: .Xr alarm 3
285: signal pending on startup.
286: .It
287: The program may have children it did not create.
288: This is normal when the process is part of a pipeline.
289: .It
290: In some non-V7 systems, users can change the ownerships of their files.
291: Setuid programs should avoid trusting the owner identification of a file.
292: .It
293: User-supplied arguments and input data
294: .Em must
295: be checked meticulously.
296: Overly-long input stored in an array without proper bound checking
297: can easily breach security.
298: When software depends on a file being in a specific format, user-supplied
299: data should never be inserted into the file without being checked first.
300: Meticulous checking includes allowing for the possibility of non-ASCII
301: characters.
302: .It
303: Temporary files left in public directories like
304: .Pa /tmp
305: might vanish at inconvenient times.
306: .El
307: .Pp
308: The following are resource-exhaustion possibilities that the
309: program should respond properly to.
310: .Bl -bullet
311: .It
312: The user might have used up all of his allowed processes, so
313: any attempt to create a new one (via
314: .Xr fork 2
315: or
316: .Xr popen 3 )
317: will fail.
318: .It
319: There might be many files open, exhausting the supply of descriptors.
1.3 christos 320: Running
321: .Xr fcntl 2
1.4 wiz 322: .Dv F_CLOSEM
1.3 christos 323: on systems which have it,
324: is recommended.
1.1 wiz 325: .It
326: There might be many arguments.
327: .It
328: The arguments and the environment together might occupy a great deal
329: of space.
330: .El
331: .Pp
332: Systems which impose other resource limitations can open setuid
333: programs to similar resource-exhaustion attacks.
334: .Pp
335: Setuid programs which execute ordinary programs without reducing
336: authority pass all the above problems on to such unprepared children.
337: Standardizing the execution environment is only a partial solution.
1.3 christos 338: .Sh SEE ALSO
339: .Xr passwd 1 ,
340: .Xr pwd 1 ,
341: .Xr access 2 ,
342: .Xr chdir 2 ,
343: .Xr chroot 2 ,
344: .Xr execve 2 ,
345: .Xr fcntl 2 ,
346: .Xr fork 2 ,
347: .Xr getlogin 2 ,
348: .Xr link 2 ,
349: .Xr setegid 2 ,
350: .Xr seteuid 2 ,
351: .Xr setgid 2 ,
1.4 wiz 352: .Xr setgroups 2 ,
353: .Xr setrlimit 2 ,
1.3 christos 354: .Xr setuid 2 ,
355: .Xr sigaction 2 ,
356: .Xr umask 2 ,
357: .Xr alarm 3 ,
1.4 wiz 358: .Xr creat 3 ,
1.3 christos 359: .Xr execvp 3 ,
360: .Xr popen 3 ,
361: .Xr printf 3 ,
362: .Xr ttyname 3
1.1 wiz 363: .Sh HISTORY
364: Written by Henry Spencer, and based on additional outside contributions.
365: .Sh AUTHORS
366: .An Henry Spencer Aq henry@spsystems.net
367: .Sh BUGS
368: The list really is rather long...
369: and probably incomplete.
CVSweb <webmaster@jp.NetBSD.org>