Date: 25 May 2000 12:34:55 +0300 From: Ville-Pertti Keinonen <will@ztango.com> To: nsayer@freebsd.org Cc: hackers@freebsd.org Subject: Re: Needed: suid library calls (was Re: cvs commit: src/crypto/openssh sshd_config) Message-ID: <86zopft1kw.fsf@ada-arm.demophon.com> In-Reply-To: nsayer@sftw.com's message of "25 May 2000 02:09:09 %2B0300" References: <sheldonh@uunet.co.za> <392C60F1.91EDC30D@sftw.com>
next in thread | previous in thread | raw e-mail | index | archive | help
nsayer@sftw.com (Nick Sayer) writes: > 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. > > I don't claim that this is an _easy_ thing to do, nor that it is a particularly > standard thing to do. (Shared) libraries are currently a userland concept. Doing what you're suggesting would require a special kind of library, controlled by the kernel and called through the kernel. In order to protect from threads and other means of sharing memory, the library would have to use its own memory for everything writable, protected against access by the unprivileged parts of the user program. This would effectively create a new ring of protection somewhere in between the "userland" and "kernel" privileges - a MULTICS concept, as Matthew Dillon noted - with its own stack and memory. On architectures that only implement user/supervisor modes of execution and don't provide segments or other kludges, such library calls would, in a sense, be executed in different processes (protection would require a separate address space - assuming that the library calls wouldn't be running in supervisor mode, in which case the entire mechanism would basically be per-process loadable system calls, also not an acceptable solution). > But the mechanism of having some sort of daemon or service whose > job it is to just do !strcmp(pw->pw_passwd,crypt(foo,pw->pw_passwd)) > is, I think, kind of overkill. It would also have to open the password database using the appropriate privileges...which in the case of a privileged library and multithreaded programs (or just rfork) is unsafe because other threads could also access the database while the library has the file handle open. IMHO a "privileged library" would, to be safe, have to be so well isolated from the rest of the program that the functionality might as well be in a separate process. 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?86zopft1kw.fsf>