Security Identifier (SID) to User Identifier (uid) ResolutionSystem

[John E. Malmberg]

Luke Kenneth Casson Leighton <lkcl at samba.org> wrote:

> > Most of the arguments presented seem to be getting circular.
>
> my arguments are not circular.  if the underlying design was circular,
> then my argument would be circular.  i'd fall on my arse without anyone
> else having to do ti for me, and i'd give up on this issue and do
> something else.

What I meant is that almost all of the messages going back and forth were
basically going over the same points and counterpoints.  No new real ground
was being covered and it really was large amount in my inbox to sort
through, especially yesterday and last night.

I also did not mean to single anyone out.  It basically was the sum of the
whole that
became circular.  Maybe not real obvious if you were looking at the messages
one at a time, but when over 80 of them show up in a mailbox at once, the
pattern was clear.

At least it was not being done that way on purpose.

And that is not to say that the points raised were not valid, it was just
that no real progress seemed to be made until:

> ok, i think we can wrap this up, now.
>
> jeremy accepted that it's ok to provide alternative mappings.  what i
> didn't want to ahve ahppen was, "it's nnot going into samba at _all_
> because i think samba shouldn't be made that complicated".


The SURS table actually is a feature that I think could be quite useful on
SAMBA on the OpenVMS operating system.

> there is no dependency between SURS tables and ACLs.  the benefits using
> SURS resolution brings are fawr more than just aACLs.  and ACLs is just
> _one_ implementation of unix file security, the other one is traditional
> unix ugo+rwx file security, and SURS tables can be used there, too.
> jeremy has alreadfy proved that this can be done: it's already in 2.0.x.


The point is that the SURS table allows me to have one generic user (POSIX
UID) for handling what I know to be an "Authenticated User".  All I have to
do in the Server process is aquire the Rights Identifiers UIDs that
correspond to the groups that the remotely authenticated User was
Authenticated to.  This basically allows me to operate in appliance mode.
This can be easily done on any host operating system that supports ACLS.  It
actually becomes simple and clean, but the ACL mappings on the POSIX host
are the key to that.

For users that have accounts on the NT domain and the POSIX domain, it
allows me to map the security on the files using the same "friendly" names.

> > With out ACLs, implementing a true trust relationship does not generate
much
> > benefit unless you simulate ACLS on behalf of the host operating system.
I
>
> simulate NT ACLs, you mean.  and the mapping between NT ACLs and unix
> file/directory permissinos does not depend on the target unix host having
> ACLs (see above).

It supplies nowhere near the same utility.  Obviously it can be done, and is
being done, but you are basically limited to the owner and two built in
groups, and having to deal with the READONLY bit.

Setting a file READONLY is easy.  Clearing the READONLY bit is problematic
for a POSIX based security system.  Should it be cleared for just Owner, or
also for Group and World?

(I do not quite remember what SAMBA actually does in this case.)  The
current main VMS port ignores those attributes, and I have not coded a
better implementation other than to accurately report the current ones for
the file.)
>
> you, as an admin, are presented with nice text names, because they are
> easy to understand instead of numbers.
>

Me an admin?  Please no name calling :-)

I make things easier for admins, but that is not my main function.

(If I seem a little confused in the usage of GIDs and UIDs, please realize
that OpenVMS does not differentiate between them at the binary security
level.  Then again, at the binary security level NT does not differentiate a
group SID from a user SID, or even what domain is authoritative for it.
That is only used for the public display.)

Seriously, while the remote NT server will supply a list of SIDs for the
user, for populating a SURS table they need to be translated to names, and
then back to UIDs or GIDs.  While I can see some wanting to map directly
from a SID to a UID/GID, in practice, the text name is the only thing that
you can control or predict it's value.  Hence the population and
de-population tools will be dependent on it.


While you have distanced the population and mapping of the SIDS to UIDS from
the implementation of how the SURS database would provide the translation,
it is not possible to build a practical system with out linking the two
issues together.

The mapping of the text name to a SID is not needed by the programs
referencing the table, so it does not need to be in the database.  And the
host operating system already knows how to translate a UID or GID into a
text name, so that text name also has no need to be in the database.
Therefore, this is not an issue for designing a SURS table or the
programming API for using it, which seems to be your focus point at the
moment.

While a few GID and UID numbers in a POSIX environment are well known as
constant, there is no way for someone other than a supplier of a canned
appliance box to predict the name to number mapping outside of that.

>From a maintenance or configuration point a view of what ever is populating
the SURS, the implementers' basically have a choice of specifying either
that this numeric GID or UID value references this text NT group or
username, or that this specific local text user or group name matches the NT
group or username.  IMHO: Most people would chose a text name to text name
mapping.  And if possible, the exact same names.


> me, as an OS, needs to use SIDs and uids for security reasons.  if me, as
> a OS, starts using text names, you end up with security breaches when
> someone deletes a users and crecreates it with the same name.

SID values are deliberately hidden for that reason, and are really only seen
by programmers that poke under the hood.

The possibility of the reuse of a UID or GID inappropriately is a fact of
life for a POSIX compatible system.  The SURS table does not affect this at
all.  Some population/depopulation algorithms can help there, but there is
nothing to inherently make the problem go away.

Your converse case is where a user is either accidentally deleted, or
because of in interesting bug in NT must be deleted and then recreated.  At
this point, not being able to force a SID is a PITA.

Because of this the NT model does not recommend that the SID that
corresponds to the USERNAME be actually used for granting access to anything
other than their personal unshared home files.  For all security issues the
SID that corresponds to a group that the user is a member of should be used.

And that SID would be mapped to a GID represented by a text name on the
POSIX system.

If the GID is what controls access, then there is no security breach unless
the group name issued on the POSIX system corresponds to a GID that was used
by a different group name in the past, and the proper cleanup was not done.
But that just means that the local administration of that system is bad.

-John
wb8tyw at qsl.net