<3D251B54.50205at_private> <20020705040920.GS26023at_private> --text follows this line-- Brian Hatch <vuln-devat_private> writes: > You'd only really need one suid program to do this if you write it > to read a config file, ala > > $ cat uid-granter.conf > # invoking-program expected-user suid-to, ... > > /usr/sbin/sshd sshd * What's the point in stripping root from sshd if it is able to run a shell as any user (including root)? You could restrict root logins and put !root there. You'd at least have to take a route over an admin account. > /usr/sbin/imapd imapd !root,* What does imapd need this kind of privilege for? Ensuring that mail spools exist and are writable by imapd should be enough, no? > I think that authentication (PAM) should be very separate from > any uid-granting executable. And really, I can't see a way > to make it work all in PAM anyway. The benefit of putting both in one place is that you could have one trusted (hopfully well-audited) component, that hands out uids (or any privilege, really) if you provide them with the proper authentication token (password, answer to RSA challange, etc.) The Hurd's password server is such a service. Give it joe's password, and it gives you joe's uid. You can have su or telnetd with no special privilege this way. > Getting that change to a standard kernel is not likely, > unfortunately. As someone already mentioned, there is a maze of twisty little solutions, all different. A more widely accepted standard is some years off (at least). -- Robbe
This archive was generated by hypermail 2b30 : Mon Jul 08 2002 - 10:18:34 PDT