Date: Thu, 25 May 2000 17:46:15 -0700 (PDT) From: Kris Kennaway <kris@FreeBSD.org> To: nsayer@freebsd.org Cc: "Jeroen C. van Gelderen" <jeroen@vangelderen.org>, freebsd-hackers@freebsd.org Subject: Re: Needed: suid library calls (was Re: cvs commit: src/crypto/openssh sshd_config) Message-ID: <Pine.BSF.4.21.0005251736170.44741-100000@freefall.freebsd.org> In-Reply-To: <392C60F1.91EDC30D@sftw.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <forsythe@alum.mit.edu>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0005251736170.44741-100000>