> -ACLs could be used to limit which uids can bind which ports. The LIDS kernel patch for Linux does something like this (but based on program, not uid.) So this is definately something doable. > The telnetd program would run as uid telnetd. > Some unix systems have this capability already from what I understand... > I'd be interested in having people mail me privately which ones do, and how > close they are to this scheme, and I'll summarize for the list. There's no reason that a login-type program couldn't run as a non-root user. It'd need a helper application that's able to perform the authentication (for example pam_unix calls a setuid /sbin/unix_chkpwd program to check /etc/shadow, allowing PAM-aware processes to authenticate without being root themselves). However it'd also need a helper app to become the new user. While you can pass filedescriptors to other processes > For something like a telnetd, > or sshd that uses PAM.... in order to drop to a shell as the uid of the > authenticated user, do they really need root? You need *something* that's running as root. It may not be the process itself, but there must be something that can hand off a new UID. Take suexec, part of Apache. It's a suid executable that has a quite rigid set of conditions that must be correct for it to run a CGI as a different user. The most important rule being that the suexec program is only called from the webserver user, which is specified at suexec compile time. Something like this would be needed for user 'telnetd' to let you log in as you, instead of it. > If you have the > authentication information for the user, then you could call the system > call equivalent of su, right? If you have the password, sure, you could do something like that. But many authentication schemes (ssh identities, challenge/response, etc) do not offer you the actual password, so you're stuck getting a different UID by some setuid() call. It's possible for a process to hand off an open file descriptor to another process (these processes must already have a pipe open between them over which the file descriptor is passed.) If there were some way to have a master 'setuid' server, available to pass access to a new UID, that be a way to avoid a setuid program, but I can't think of any way to do this. > What would be wrong with doing things this way (other than having to code > it)? You're traiding UID root for suid root helper programs. Now whether this is 'wrong' or not depends on your thinking. -- Brian Hatch Thou shalt not pray Systems and to Zeus for things Security Engineer your usual god would www.hackinglinuxexposed.com laugh at. Every message PGP signed
This archive was generated by hypermail 2b30 : Thu Jul 04 2002 - 20:50:09 PDT