Date: Thu, 21 Aug 2003 13:40:10 -0400 From: ari <edelkind-freebsd-hackers@episec.com> To: freebsd-hackers@freebsd.org Subject: Re: [future patch] dropping user privileges on demand Message-ID: <20030821174010.GA55671@episec.com> In-Reply-To: <20030821170122.GC10811@webserver> References: <20030817181315.GL55671@episec.com> <20030821065854.GA11586@dan.emsphone.com> <20030821073900.GA90003@rot13.obsecurity.org> <20030821170122.GC10811@webserver>
next in thread | previous in thread | raw e-mail | index | archive | help
oremanj@get-linux.org said this stuff: > On Thu, Aug 21, 2003 at 12:39:00AM -0700 or thereabouts, Kris Kennaway wrote: > > > > Exercise for the reader: find a situation where the failure to perform > > a syscall that normally succeeds, leads to privilege escalation :-) > > setuid(), seteuid(), setruid() There seems to be some misunderstanding of what kris meant. He was referring to a system call that is so poised to succeed that programmers will often not bother checking for an error value. For example, if one winds up not having privileges to call exit(), then, say, an authentication failure may not abort execution. If close() is not allowed, then a sensitive file descriptor may be left open as the program continues to run. If unlink() fails, one may fall victim to following an unintended symbolic link upon file creation. If chroot() or chdir() fails, a program may not be able to properly insert itself into a chroot() environment. If getpid() fails, the program may not properly distinguish intended privileges. If mprotect() fails, one may not be able to remove the writable bit from a memory page. If munmap() fails, one may suffer memory leaks. If quotactl fails, user quotas may not take effect. The setuid() family of functions will only cause a problem here if a program is either running as root or has a saved or effective uid that is different from its real uid. Even then, having setuid() disabled may be either beneficial or detrimental, depending on what the programmer expects or is attempting. There are all sorts of ways for the failure of system calls at inopportune times to lead to an elevation of privileges. But the point is, this isn't (or shouldn't be) for the administrator to worry about; the programmer knows that while modifying his code, he should be careful not to introduce security problems. If a programmer is able to disable the exit() system call, he should know what he's getting himself into when he does so. The patch i'm proposing isn't going to allow the disabling of arbitrary system calls; not every function call will even be included in a class. For example, the ability to block memory-related routines would probably not be a good idea, and doing so may break your program, depending merely on which standard c library you use. If you expect memory leaks, resource limits can keep your process at bay. ari
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030821174010.GA55671>