Re: Ports 0-1023?

[Brian Hatch <vuln-dev () ifokr org>]

> -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

Attachment: _bin
Description: