From owner-freebsd-hackers Thu May 25 17:46:19 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 7A49137BE23; Thu, 25 May 2000 17:46:16 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id RAA46410; Thu, 25 May 2000 17:46:16 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Thu, 25 May 2000 17:46:15 -0700 (PDT) From: Kris Kennaway To: nsayer@freebsd.org Cc: "Jeroen C. van Gelderen" , freebsd-hackers@freebsd.org Subject: Re: Needed: suid library calls (was Re: cvs commit: src/crypto/openssh sshd_config) In-Reply-To: <392C60F1.91EDC30D@sftw.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 24 May 2000, Nick Sayer wrote: > What we _really_ need is some mechanism to recognize the difference > between a user program and a system library, with an eye towards > granting privileges to trusted libraries without letting those privileges > leak past the library in question. Let's think about this for a minute. In order to do that securely, the unprivileged code should not be able to read from, or write to, memory used by the "privileged library". If you can read from it you can potentially snarf the contents of buffers as it reads privileged files, and if you can write you can probably hijack it and cause arbitrary code to be executed with privileges. So the library needs to run in its own memory protection domain. Except for the matter of co-scheduling, you're basically talking about a separate process communicating via IPC. This is what has already been suggested :-) > User authentication is only one example. There are many things that > only root can do where letting non-root do the job is not dangerous, > but granting non-root permission in a general way is. Another good > example is daemons that must bind listening sockets <1024, but don't > need root otherwise. The entire binary must be suid up to the bind, at > which point the program may renounce the suid bit > (setreuid(getuid(),getuid());). Wouldn't it be more secure if a > library could selectively grant low ports to _selected_ non-suid > programs (perhaps with a config file)? This is an example of a capability. Capabilities provide elevated kernel privileges to processes in discrete chunks, i.e. as a subset of what root can do. The TrustedBSD project (led by Robert Watson) is developing code to provide POSIX.1e capabilities to FreeBSD (among other nifty things). Your other example doesn't fit well into the capabilities model, because authenticating against private credential databases (e.g. /etc/master.passwd) is a privileged userland operation, not a kernel one. Kris ---- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message