[EMAIL PROTECTED] writes:
> > Oh.  I though that pidentd was supposed to resolve UIDs locally.
> > That's one of the features of the protocol; it provides "here's who
> > *I* think the user is" information back to the requester.
> 
> Of course, that's why I thought IDENT was a fairly bogus mechanism
> since you're asking the remote system to report on its own users and
> someone who controls that machine can report whatever their heart
> desires.

It has its value, you just have to know how to use it.

> Or has the mechanism changed over the years?  Has there been any work
> in the IETF, for example, to try and develop something more useful than
> identd?

No.

The value is this: it provides you a way to ask for a durable but
unauthenticated identifier of some sort (doesn't really matter what
sort -- it's opaque as far as the receiver is concerned) to associate
with that connection.  The purpose is for debug and hunting down
abusers with cooperating admins.

It's no more or less secure than the source port number.

In other words, instead of saying "I saw a connection at 2:34PM
yesterday from 10.0.0.1:5678, and it looks like he was trying to hack
into my system; can you talk to this user?"  You can say "I saw a
connection at 2:34PM yesterday from 10.0.0.1:5678 from someone your
system identifies as 'FooBar,' and it looks like he was trying to hack
into my system; can you talk to this user?"

If that *remote* admin is himself useful (he may not be) and if he
trusts the value from his own IDENT report (he should), then it'll
give him an easier time tracking down the offender.

If you don't do this, then the only thing that poor remote admin has
to go on is the socket parameters, and that's very little data for a
multiuser system.  It's effectively useless, unless that remote admin
is a weirdo who is logging every single packet along with local UID.

It all hinges on cooperating system administrators for multiuser
systems.  If you don't have that, then you have to go to higher layers
(using address alone, assuming single-user systems, uRPF, and address
assignment that relates to the user) or higher still (service
providers).

-- 
James Carlson, Solaris Networking              <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

Reply via email to