Re: dumb question

[Zack Weinberg <zack@rabi.phys.columbia.edu>]

On Tue, 30 Jun 1998 22:29:15 +0400 (MSK DST), "A.N.Kuznetsov" wrote:
>Hello!
>
>> > The BSD implementation ignores what the sender passed in and supplies
>> > the receiver with the pid, the real and effective uid, the real and
>> > effective gid, and the first 15 entries in the supplementary groups
>> > list.
>> 
>> 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 BSD implementation of group passing seems to be nice
>> 
>> > So: would the kernel people be willing to change SCM_CREDENTIALS to
>> > work the BSD way?  I don't think the Linux way has any installed base
>> > of user code to speak of.
>> 
>> You need to ask Alexey <kuznet@ms2.inr.ac.ru>. It looks good to me. Since
>> we have no standard and they have a better design IMHO I think we should
>> bite the bullet on this one for the good of unix security in general.
>> 
>> (Alexey if you think this is OK I'll do the changes)
>
>I do not think that it is OK.
>
>About group IDs: it sounds good but there is one technical
>problem here. Our implentation ALWAYS stores credentials and
>we have no room for storing group ids and, in any case,
>it would be too expensive. Besides that, I found no useful
>applications for it. 8) At least, original inventor (Solaris)
>uses only euid, even gid is not used. And the reasons for this
>are clear, see below.

Ok, fine.

>About BSD variant. I thought for pretty long time,
>before I choosed this variant with only ONE uid and
>only ONE gid and chance to user to select one
>from set of allowed values (*id,s*id,e*id).
>I still believe it was correct decision.
>
>Do not forget also that unix group ids and differences
>between uid/suid/euid etc. are almost non-sense in networked
>environment. If we want good security, we will use "principals"
>and access lists in any case. Sure, suppl. groups are much faster,
>when used inside host, but their real value in networked
>cluster are zero, so that I see no reasons to rely on
>them even locally.

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.

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.

It is simpler, faster, and more secure to have the kernel ignore the
input buffer and always write what it knows to be the truth.  I'd
settle for { pid, ruid, rgid, euid, egid } which libc can rewrite to
the BSD interface.  Since binary compatibility is a concern, check the
buffer size and leave off the last two if it's the old small buffer.

zw