Re: dumb question

["A.N.Kuznetsov" <kuznet@ms2.inr.ac.ru>]

Hello!

> >> Well we actually wrote it first so blah 8) 
> >
> >Alas, the first was SunOS-5.
> 
> Really?  It's not documented anywhere nor is it findable in any of the
> headers.  (2.5.1)

The declaration was in solaris<=2.3, but it was removed in 2.4,
(it is not wonderful, it was ugly(TM) 8))
Solaris 2.5.1 uses its interface internally inside its rpc library,
keyserv and rpcbind. Luckily, I was enough clever to save
2.3 include files before upgrade to 2.4, so that I still can compile
keyserv and rpcbind for solaris 2.5.1 8)8), and they even work 8).

BTW the most first version of tirpc port (I did it, when Solaris 2.3 was
not obsolete yet) mimiced Solaris interface. And only when I understood,
that Solaris people does not like it very much too, I finally moved
to pure SCM_CREDENTIALS.

> But this call is one that only works over local sockets.  Naturally a
> network SCM_CREDS call is nonsense -- you have to do it in userland,
> with principals, access lists, encryption, etc.

It is true, but it is not full truth. F.e. tirpc is transport independent,
so that the difference between local and not-local transports
is invisible by aplications. Actually, secure rpc is exactly
mapped to pure uid, so that SCM_CREDENTIALS + secure rpc form
natural network wide authenthenticated space.


> The only part of the existing implementation that I am really opposed
> to is the part where the superuser can lie about his identity.  That
> makes the entire arrangement untrustworthy.  A subverted set-id
> program can impersonate any user.  (I am thinking particularly of a
> mail daemon that uses SCM_CREDS to put an unforgeable sender label on
> outgoing mail.)  On the flip side, the possible utility in being able
> to forge SCM_CREDS is minimal to nonexistent.

??? You say strange things. Intruder who stole CAP_SETID will make
with your local hosts any thing, which he is able to make.
And SCM_* has nothing to do with it.
The only goal of SCM_CRED* is to give one more authentication
flavor, which is equivalent to unix uid authentication.
I have no objection against passing suppl. group ids,
when it will be possible technically.


Yes, CAP_SETID process CAN lie about its identity, and it DOES lie.
F.e. when setuid binary need to get key for real user.
Moreover it is advantage of this interface, because
CAP_SETID process does not need to switch its ids
and, hence, to create potential race conditions and
holes, sort of signal windows.

And it is the feature, which I do not want to loose.
CAP_SETID process should have possibility to pass fake
credentials without real switching to them.


Seems, you make usual error, which used to poison unix security.
Authentication and authorization are different things, they
are not related at all.

The fact, that user is authenticated as (uid,...) does not
mean that it is allowed to make all the things, which are allowed
generally for (uid,...). F.e. we cannot allow to change password,
we does not give out to him his its secret DH key etc. etc. etc.
These operations requires special, much more strong authentication.
And it is good place to repeat: The only goal of SCM_CRED* is to give
one more authentication flavor, which is equivalent
to unix uid authentication, with the same trust level.

Alexey