Re: Needed: suid library calls (was Re: cvs commit: src/crypto/openssh sshd_config)
[EMAIL PROTECTED] (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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Needed: suid library calls (was Re: cvs commit: src/crypto/openssh sshd_config)
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 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Needed: suid library calls (was Re: cvs commit: src/crypto/openssh sshd_config)
"Jeroen C. van Gelderen" wrote: [...] Since user authentication is needed by more than one program it should live in it's own process. Right now there is code duplication and it is impossible to change the authentication policy without messing with sshd. 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. 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. Perhaps some sort of syscall to change the euid that only works in privileged libraries would work. 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)? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Needed: suid library calls (was Re: cvs commit: src/crypto/openssh sshd_config)
:"Jeroen C. van Gelderen" wrote: : : [...] : : Since user authentication is needed by more than one program it : should live in it's own process. Right now there is code : duplication and it is impossible to change the authentication : policy without messing with sshd. : : :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. Oh god, its MULTICS! Run! Run! Run for the hills! -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Needed: suid library calls (was Re: cvs commit: src/crypto/openssh sshd_config)
Matthew Dillon wrote: [lost attribution. Nick wrote this] : :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. Oh god, its MULTICS! Run! Run! Run for the hills! See? Final proof that those who don't know history are bound to repeat it. :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Needed: suid library calls (was Re: cvs commit: src/crypto/openssh sshd_config)
Matthew Dillon wrote: :"Jeroen C. van Gelderen" wrote: : : [...] : : Since user authentication is needed by more than one program it : should live in it's own process. Right now there is code : duplication and it is impossible to change the authentication : policy without messing with sshd. : : :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. Oh god, its MULTICS! Run! Run! Run for the hills! Hold on! I only spoke the first part, mind your quoting pleaz! Cheers, Jeroen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
